Importing meteor-node-stubs in a statically analyzable way is important to
ensure all the aliases for built-in Node modules get set up properly. This
does *not* mean that all meteor-node-stubs/defs/* modules will be imported
unconditionally.
Part of #6562.
What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
The implementation of these stubs is controlled by an optional npm package
called meteor-node-stubs, so we can keep iterating on them after releasing
Meteor 1.3, if we need to.
Fixes#6056.
The beta released with this commit (modules-beta.6) included everything on
the release-1.3 branch up to bdf64da339
("Avoid circular package.json resolution chains.").
Unfortunately, additional commits were pushed to the branch before this
commit was pushed, so the release tag release/METEOR@1.3-modules-beta.6
does not correspond to any commit in the branch history.
Rather than attempting to rewrite the branch history, I decided to amend
this commit with this explanation before pushing it.
To see exactly what was released with the sixth beta:
git fetch --tags
git log release/METEOR@1.3-modules-beta.6
Instead, we rely on the fallback function defined in
meteor/packages/modules/modules.js to resolve meteor/package identifiers
at runtime. The ImportScanner also now warns if no such Meteor package
seems to be available.
Package stubs were a clever hack, but eliminating them means every module
installed by meteorInstall now corresponds to some actual module file.
Apparently we can't realistically track wrapped package version
numbers because you're required to have a pre-release identifier
at the end of package versions when releasing a pre-release
version of Meteor.
