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
Fixes the error reported in the 1.6.1 pull request. (Thanks, @yorrd!)
It's worth nothing that the `DDP._allSubscriptionsReady` function which
was broken is used by the deprecated `spiderable` package. Since
`spiderable` is deprecated, it's advisable to look into ways to stop
depending on it.
Refs: https://github.com/meteor/meteor/pull/9274#issuecomment-345358178.
Since bundle-visualizer is a non-core package, it could be used with a
version of ecmascript that does not imply dynamic-import, though it
definitely requires support for `import()` to function properly.
Since the new version of ecmascript depends directly on dynamic-import,
it's important that it's a version of dynamic-import that does not depend
indirectly on ecmascript, and I'm not sure if the constraint solver can
figure that out easily without a little help.
Even a weak dependency affects the load order of packages by forcing the
depended-on package to load before the dependent package. Waiting until
Meteor.startup to check for Package["browser-policy-common"] dynamically
does not have this problem.
If you're trying to visualize the bundle of an application that does not
use ddp-client, it's annoying if bundle-visualizer pulls in all those
dependencies just to support itself.
cc @abernix
Now that dynamic-import no longer depends indirectly on ecmascript, the
ecmascript package can finally guarantee support for dynamic `import()`,
as it rightfully should.
Now that we're using HTTP POST requests to fetch dynamic modules, it's
more important to make fewer requests when possible, given the higher
latency of HTTP requests compared to WebSocket messages.
The trick is to wait until the next tick of the event loop before actually
sending the request, so that multiple dynamic import() calls in quick
succession are treated as a single request, and all the modules they
require can be returned in a single response object.
For example, we want code like this
const [
React,
ReactDOM
] = await Promise.all([
import("react"),
import("react-dom")
]);
to result in one HTTP POST request for both `react` and `react-dom`, as
well as all their dependencies, rather than two separate requests.
Indeed, that is what happens, since both import() calls take place in the
same tick of the event loop.
Letting dynamic-import depend on packages that depend on ecmascript means
ecmascript and its dependencies can't depend on dynamic-import. This
commit gives us back that flexibility.
Each time the server starts, the dynamic-import/server.js module creates a
secret key for accessing dynamic server modules, then exposes that key to
the server-side dynamic-import/client.js module, and no one else.
If client.setSecretKey has been called, that key will be included as a
query parameter in each /__dynamicImport POST request. If it matches the
actual secret key, access is granted to the corresponding dynamic modules;
otherwise, only web.browser dynamic modules are made available.
Ever since Meteor 1.5 first shipped, dynamic modules have been fetched
over a WebSocket, which is appealing because sockets have very little
latency and metadata overhead per round-trip.
However, using a WebSocket requires first establishing a socket connection
to the server, which takes time and may require a WebSocket polyfill.
An even more subtle problem is that we cannot use dynamic imports in any
of the code that implements the ddp-client package, as long as the
dynamic-import package depends on ddp-client.
By switching from WebSockets to HTTP POST requests, this commit radically
reduces the dependencies of the dynamic-import package, while preserving
(or even exceeding) the benefits of socket-based dynamic module fetching:
1. The client makes a single HTTP POST request for the exact set of
dynamic modules that it needs, which is much cheaper/faster than making
several/many HTTP requests in parallel, with or without HTTP/2.
2. Because the client uses a permanent cache (IndexedDB) to avoid
requesting any modules it has ever previously received, the lack of
HTTP caching for POST requests is not a problem.
3. Because the HTTP response contains all the requested dynamic modules in
a single JSON payload, gzip compression works across modules, which
produces a smaller total response size than if each individual module
was compressed by itself.
4. Although HTTP requests have more latency than WebSocket messages, the
ability to make HTTP requests begins much sooner than a WebSocket
connection can be established, which more than makes up for the latency
disadvantage.
5. HTTP requests are a little easier to inspect and debug in the dev tools
than WebSocket frames.
6. The new /__dynamicImport HTTP endpoint is a raw Connect/Express-style
endpoint, so it bypasses the Meteor method-calling system altogether,
which eliminates some additional overhead.
7. Fetching dynamic modules no longer competes with other WebSocket
traffic such as DDP and Livedata.
8. Although the implementation of the /__dynamicImport endpoint is a bit
too complicated to allow serving dynamic modules from a CDN, that
remains a possibility for future experimentation. In other words, how
modules are fetched is still just an implementation detail of the
`meteorInstall.fetch` callback.
9. As with the WebSocket implementation, the module server is totally
stateless, so it should be easy to scale up if necessary.
I wish I had appreciated the advantages of an HTTP-based implementation
sooner, but I think the transition will be pretty seamless, since the new
implementation is completely backwards compatible with the old.
I replaced the ecmascript package with just the modules package so that
ecmascript and its dependencies can depend on http without creating
package dependency cycles.
I also took this opportunity to upgrade the `request` npm dependency to
its latest version (2.83.0), and removed the `deprecated.js` file, which
used to define `Meteor.http`.
