This should make the @babel/runtime dependency that I added to the
compile-coffeescript plugin in a52a2c28f1
actually work as intended.
Specifically, the babel-runtime package that's bundled into the
compile-coffeescript plugin will now be able to import @babel/runtime and
receive the plugin's private version of @babel/runtime, rather than the
one in dev_bundle/lib/node_modules or the application's node_modules.
cc @hwillson @abernix
With this commit, if a top-level package version constraint in
.meteor/packages ends with a '!' character, any other (non-!) constraints
on that package elsewhere in the application will be weakened to accept
any version of the package that is not less than the constraint,
regardless of whether the major/minor versions actually match.
This functionality is extremely useful in cases where an unmaintained
package was last published with api.versionsFrom(<some ancient version>),
thus constraining the major version of any Meteor core package it depended
on, but you really want to upgrade that core package anyway. Just put a
'!' after the core package's version constraint in your .meteor/packages
file, and you will almost certainly get your way. The fact that minimum
versions are still enforced is good/fine because the constraints you want
to override are typically ancient, so they easily match any recent version
of the package.
Your only recourse before this @x.y.z! syntax was to find a replacement
for the unmaintained package, or fork and modify it locally, or somehow
persuade the package author to publish a new version with a more
reasonable api.versionsFrom. None of these options were easy.
Many thanks to @GeoffreyBooth, long-time maintainer of the `coffeescript`
package, for originally suggesting a ! syntax similar to this one:
https://github.com/meteor/meteor-feature-requests/issues/208#issuecomment-400154209
The limitation of this syntax to .meteor/packages is deliberate, since
overriding package version constraints is a power-tool that should be used
sparingly by application developers, and never abused by package authors.
Also, limiting the scope of this syntax reduces the risk of an arms race
between overrides, a la the infamous CSS !important modifier.
According to the plan described in #10134, whereas we had to pin these
versions to exactly 7.0.0-beta.55 for Meteor 1.7.0.4, we must now require
at least 7.0.0-beta.56 for Meteor 1.7.1, since other @babel/... packages
used by babel-compiler and meteor-babel are currently at beta.56.
The ImportScanner was mistakenly generating module.useNode() stub modules
for local .json files within Meteor packages, just because their absolute
module identifiers include "node_modules", which happens because we put
package modules under the /node_modules/meteor/<package name/ namespace.
Fix: make logic for determining when to generate module.useNode() stubs
match Module.prototype.useNode logic in modules-runtime/server.js.
Closes#10122.
Probably the most notable change in this update is that the Reify compiler
now generates
module.link("./child", { ...setters... });
instead of
module.watch(require("./child"), { ...setters... });
for import and export-from declarations.
Thanks to these commits in the Reify project, there's a new runtime module
system method: module.link(id, setters), which replaces the previous (more
cumbersome) module.watch(require(id), setters).
This is more than a cosmetic change, since it will allow creating module
Entry objects before evaluating modules, which will help improve spec
compliance around import cycles and hoisted function declarations.
It's also shorter than the module.watch style, which is always nice.
However, since require(id) no longer appears in the generated code, we
can't just rely on findImportedModuleIdentifiers looking for require
function calls, so the scanner now needs to look for module.link(id, ...)
calls as well.
Because in-place rebuilds are disabled by default on Windows, we were
losing .meteor/local/build/programs/web.browser.legacy every time we
rebuilt .meteor/local/build as part of writeSiteArchive, as reported by
@lmachens in this comment: https://github.com/meteor/meteor/pull/9942#issuecomment-406656741
In-place rewriting of .meteor/local/build seems essential for the new
strategy of writing different targets at different times, though I have
attempted to limit the risk of overwriting open files on Windows by
continuing to build the individual target directories from scratch (that
is, by writing a fresh temporary directory and then renaming it over the
existing directory).
Though I don't have any specific ideas in this direction, it may be worth
noting: if we could find a way to make in-place builds safer on Windows
(as they are on Linux and Mac), Windows rebuilds would be significantly
faster than they are with the current strategy of rewriting everything
from scratch every time.
The defaultExtensionHandlers[".json"] function in import-scanner.js sets
file.jsonData as a side effect, which is important because that's what the
linker uses to construct a stub module.exports object for dynamically
imported package.json modules.
When I introduced ImportScanner#_readPackageJson as an alternative to
ImportScanner#_readModule in a recent commit, I intentionally did not call
defaultExtensionHandlers[".json"], but in so doing I neglected to preserve
the behavior of setting file.jsonData.
Without a proper package.json stub with at least a "main" property, the
dynamic import() system can't resolve dynamically imported packages until
the full package.json module has been fetched from the server, which leads
to missing module errors in the initial dynamic import().
Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
https://github.com/meteor/meteor/pull/10055#discussion_r201855997
As I explained in this comment, Package._on(packageName, callback) was a
bad API because it never called the callback if the package was not
installed, which caused any app not using the autoupdate package to get
stuck trying to communicate with the autoupdate package.
