This temporarily reverts back to using @babel/runtime/helpers/* rather
than @babel/runtime/helpers/builtin/*, since some helpers (for example,
`slicedToArray`) were using code patterns that cannot be made to work via
polyfills in older browsers, e.g.
if (Symbol.iterator in Object(arr)) {...}
to test whether `arr` is iterable.
While running the tests three times might make a lot of sence in CI
environments, it certainly slows things down in development, especially
when you've failed a test on purpose, but still have to wait for it to
run three times to get the output.
This not only implements the `--retries` flag, but also activates it in
both CircleCI and AppVeyor test suites.
Most of the work to prepare for this change was done through the
excellent work of @hwillson in meteor/meteor#9173 which, after some
re-working to support the 64-bit architecture on Windows platforms,
landed in meteor/meteor#9218, making this change as simple as bumping
the minor version number (and rebuilding the dev bundle).
From this point forward, and due to Mongo's discontinuation of 32-bit
support in newer versions of MongoDB, 64-bit platforms will, in
development, use newer versions of Mongo while 32-bit architectures
will remain at 3.2.x versions.
Of course, in production, apps are free to use whichever version of
Mongo they would like, provided that version is supported by the
Node Mongo driver and Meteor's Mongo data packages. At this time
there is no target for when Meteor will stop supporting Mongo 3.2,
but developers are encouraged to take steps to upgrade their Mongo
deployments (through their database providers) to newer versions
since Mongo has set September 2018 as the "End-of-Life" for Mongo
3.2.x. For more information on Mongo support cycles, see their
support documents at https://www.mongodb.com/support-policy.
Refs: https://github.com/meteor/meteor/pull/9173
Refs: https://github.com/meteor/meteor/pull/9218
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.
This puts Meteor back on the official release track of Node.js 4, rather
than using its own custom build (from https://github.com/meteor/node/),
which had previously been necessary to add the garbage collection fixes
gained with
751f1ac08e
and
71f9cdf241,
both of which are now officially included in Node.js 4.x as of 4.8.6.
🎉
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
While the actual version included for Unix developers will be our own
build at NODE_VERSION, this is important for the Windows version, since
it is not being rebuilt by our Jenkins at the moment.
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.
