While this was necessary in previous versions of Meteor, as of 1.6 the
`self-test` tooling will automatically install the dependencies it needs
at runtime.
Not only does this allow the installation to be avoided when tests using
those facilities aren't invoked, it also allows us to reliably install
the same version of these npms, rather than falling back to the
`latest` npm tag on each CI run.
This code had been used to compile the previous generation of
the Windows installer, `InstallMeteor.exe`, however it has been
replaced with the `meteor` Chocolatey package.
Refs: https://github.com/meteor/meteor-chocolatey-installer.
Currently, three 'dynamic import' tests exist in the self-test suite:
* dynamic import(...) in development
* dynamic import(...) in production
* dynamic import(...) with cache
These tests take quite some time to run; each test takes ~5 minutes.
While it's great to test them in a faster environment (Unix), which
Meteor will continue to do, the overall value of the three separate
tests is not as great in a slower testing environment, like Windows.
While 'cordova-lib' used to live in 'dev-bundle-tool-package.js' where
it was pre-bundled into the "dev bundle", that is no longer the case.
It is now automatically installed, on demand, when Cordova is used.
This follows up on meteor/meteor#9213, which added it back to the
'dev-bundle-tool-package.js' and updates it in the new location.
Ref: https://github.com/meteor/meteor/pull/9213
Ref: 073f2410a6
cc @skirunman.
Even with $ErrorActionPreference, PowerShell won't automatically fail
when an external command fails with an error code. This explicitly
checks those exit codes and throws an error when that occurs.
Hopefully prevents false successes like that shown in this AppVeyor
test run: https://goo.gl/xxRsF9.
Though it was thought to be reliable when running through 'self-test' on
Windows, it's yet to be seen how reliable.
The worst thing that could come of adding Windows testing would be that
we have test failures again after such a string of green checkmarks and
confidence.
Also, reordered.
This implements a first generation of Windows CI testing. Presently,
this only runs valuable, hand-picked tests which have been known to work
in the past, and whose failure would indicate a critical problem.
A test which isn't passing doesn't mean that the feature being tested is
not working. For example, the 'create' test fails ostentatiously,
though the 'meteor create' command certainly works in practice. This
points to problems some compatibility problems with the 'self-test'
harness itself, some of which I'm aware of. Though, it likely will
highlight some legitimate problems which Windows users experience too.
There are a number of additional tests which should be enabled which
likely pass already, and many more which are failing and we should fix.
Additional tests can be added to the scripts/windows/appveyor/test.ps1
file as they've been deemed working.
Altogether, this will take extensive work to achieve the same level of
coverage our Unix test suite enjoy, but we've got to start somewhere!
cc @benjamn
The Generate Dev Bundle process no longer requires any modifications
to the $PATH, preventing environmental artifacts which pile up when
running the script over and over again.
I thought it was nifty to use this Cmd-let from PowerShell, to directly
parse the JSON output from Node's `process.release`, but as it turns
out, that wasn't supported by the version of PowerShell on our Jenkins
server. Alas!
This is a re-write of the generate-dev-bundle.ps1 script, which occurred
during debugging of an unrelated concern of the (new) 64-bit Windows
build on our Jenkins server. Ultimately, I'm afraid this script doesn't
solve the problem I originally set out to fix, which was a Windows
long-file path concern.
The hunch behind that thinking was that the use of npm@1 to install
npm@5 could be causing problems, since npm@1 had no concept of nested
node_modules directories. We had used npm@1 because Node.js
for Windows hasn't always offered (via nodejs.org/dist/) versions
including npm which we could use to install our own requirements.
Happily, that is no longer the case!
While this script now deals with long paths much more gracefully itself,
I'm not sure it completely quelled the long-path issue, and there are
still some directory trees which are longer than I think they should be.
The warnings I was seeing may not have harmed the actual bundle and were
more problematic for this build script itself when it tried to deal with
the aftermath of all those files, since native Windows commands struggle
to deal with long file paths (when cleaning up, etc.).
In the end, this script does have performance enhancements though! For
starters, it's nearly twice as fast at finishing. Most of this was
gained by avoiding back-and-forth moving of large file structures,
opting instead to directly install into the targets when possible.
It also ensures that the npm build cache is not bundled, which started
occurring since our modification of the $HOME and $USERPROFILE variables
led npm@5 to think the npm cache was in the root of the bundle.
Additionally, it no longer modifies the $PATH, in any way, during the
build. This became particularly helpful during testing when I found that
PowerShell maintained that $PATH in the environment of the host shell.
I'd like to say it increases readability of the script, which had
become a bit of a patchwork quilt, but that's YTBD and YMMV.
This is my first "complete" PowerShell script myself so it probably
still leaves some things to desired, formatting wise. Functionality-
wise, I hope it's improved.
The Windows 64-bit support is believed to be important enough to be
included in Meteor 1.6 since it fixes Meteor 1.6 issues on Windows.
While the original reason for 64-bit may have been Mongo, we'll leave
this as the 3.2.15 (but 64-bit!) version for now.
