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`.
Fixes an issue preventing the installation of scoped Cordova
packages. For example,
`meteor add cordova:@somescope/some-cordova-plugin@1.0.0`
will now work properly.
Fixes https://github.com/meteor/meteor/issues/7336.
* Adjust observeChanges skip/limit ordered observe error message
The `Cursor.observeChanges` function throws an error when there
is an attempt to use an unordered observe with skip/limit.
This error can also be thrown when attempting the same thing
with `Cursor.observe`. This is because `Cursor.observe` ends
up calling back to `Cursor.observeChanges`. When using
`Cursor.observe` however, the shared error message
is a bit misleading, as `addedAt` should be used instead of
`addedBefore`. This commit adjusts the shared error message to
cover both `observeChanges` and `observe` scenarios.
Fixes#4996.
* Bump minimongo patch version
Now that es5-shim has no impact on modern browsers (thanks to selectively
server-side rendering a <script> tag for older browsers), there's very
little reason not to use it.
If you really don't want to use it, you can always remove meteor-base and
install your preferred set of base packages.
Just as we were able to remove the SockJS polyfill library entirely from
the client JS bundle for modern browsers (#9353), we can do the same with
the `es5-shim` package.
The removes 28KB from the size of the minified JS bundle (before gzip).
It is no longer necessary for other packages to register weak dependencies
on `es5-shim`, because `es5-shim` will be reliably loaded in the `<head>`
if installed, which guarantees it will be evaluated before any bundled JS
in packages or the application.
In addition to loading `es5-shim` and `es5-sham` using `<script>` tags on
the client, we no longer evaluate either script on the server, since Node
8 has solid support for everything that previously needed shimming.
