The react-dom@16 npm package recently got stricter about how it checks
that dead code elimination is enabled. Specifically, it no longer just
checks that process.env.NODE_ENV is replaced with "production" but also
requires conditional branches to be completely removed if the replacement
makes them unreachable:
https://github.com/facebook/react/blob/master/packages/react-dom/npm/index.js
The minifier-js package recently had its minor version bumped for Meteor
1.6, so I think it's safe to enable dead code elimination in a patch
version update. If we bumped the minor version again (to 2.3.0), this
version of minifier-js would not be usable with Meteor 1.6, and would
probably have to wait for Meteor 1.6.1.
Bumping the patch version of standard-minifier-js is also necessary
because it uses minifier-js as a compiler plugin, and would otherwise
continue to bundle the old minifier-js plugin.
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.
* Make behaviour of cursor.count() on client reflect server
* Change ignoreSkipLimit to applySkipLimit in cursor._getRawObjects
By default cursor._getRawObjects() will set options.applySkipLimit to true, thereby honoring any skip / limit.
cursor.count() on the client now calls _getRawObjects with applySkipLimit set to false by default. See #1202
* Revert default behaviour of cursor.count() to maintain backwards compatibility
These take precedence over the UI, and I'm not sure the UI is taking
effect at the moment.
We don't need to build branches which start with 'dev-bundle-' since
those dev bundles won't be built yet when the tests are kicked off.
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
