The `meteor build --architecture` help was missing
`os.windows.x86_64`. This commit adds it in and also updates
an out of date comment in the source that referred to there
only being 3 allowed architectures.
As explained in the entry for the `meteor` command, the first line of each
entry in help.txt is the summary for autogenerated command lists, and thus
will not be displayed in the help for the command.
The uglify-es minifier sometimes inlines (0,Package.modules.meteorInstall)
as a callee expression rather than declaring a variable, so this commit
adds support for that minification technique when computing bundle size
statistics for the bundle-visualizer package.
One symptom of this bug: while the bundle-visualizer displays packages
minified in this way with the correct total size, they appear not to have
any node_modules.
cc @abernix
* Adjust test filename RegExps to match Meteor guide. Fixes#9332.
* Adjusted help text for --drive-package on meteor test.
* Add integration tests for `meteor test` eager file loading.
* Fix typo in selftest.forbid comment.
* Improve test file eager load integration test coverage and clarity.
* Update the default CSS parsing/combining/minifying tools
The `minifier-css` package is currently using outdated
(and abandoned) npm packages (`css-parse` and `css-stringify`),
as part of its parsing/minification process. This commit
replaces those packages with the robust, modern and maintained
`postcss` package.
* Adjust CSS source file fallback value
* Self test adjustments and cleanup
* Disable sourcesContent generation by postcss
The `standard-minifier-css` package is already associating
source content with the source map, so we don't need to
do this twice.
* Add History.md entry covering backwards compatibility details
* Bump major version due to backwards compatibility breaking changes
* Bump minor versions
* Code review changes (boolean formatting, concat to spread)
Hopefully, without too much effort, it will be easy to reintegrate much of
the automated BrowserStack testing we (mostly) already had in place! In the
near future, this could be helpful for ensuring we're not over/under-shipping
polyfills to browsers.
Hopefully we can keep this green, though it's not clear to me at the
moment what additional changes I'll need to make to ensure that. For
now, badge!
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
Store the result of any npm error logs which may prove useful
during investigation of random Windows failures, exhibited in
the Windows `dynamic-import` tests during npm installation:
https://ci.appveyor.com/project/meteor/meteor/build/368
