With Node.js 8.x nearing end-of-life status at the end of this year, and
Node.js 12 now in LTS, we think it makes sense to finalize Meteor 1.9
sooner rather than later, and continue working to take advantage of all
the great features of Node 12 in future 1.9.x releases.
As usual, the meaning of "release candidate" is that we can still fix bugs
before the final release, but there will be no new features added.
Now that Meteor 1.8.2 has moved to the RC phase of testing, I think it
makes sense to promote Meteor 1.9 from alpha to beta, especially if we are
hoping to release Meteor 1.9 around/after October 1st, when Node.js 12
offically enters Long-Term Support (LTS).
We don't need to build a whole new dev bundle just for this upgrade, since
we've already worked around the bug that it fixes, but it will get picked
up the next time we build the dev bundle for Meteor 1.8.2.
This ensures we wrap modules with a function to rename the `module`
identifier to something more reliable when the ImportScanner compiles
unanticipated modules imported from node_modules.
Should fix#10595.
Code from the application `node_modules` directory becomes part of the
`modules` package, so that it can be imported by any other package that
uses the module system, regardless of package load order.
Now that we compile code from `node_modules` using `babel-compiler` and
`meteor-babel` (#10585), `node_modules` code requires the same runtime
environment as any other Meteor JS code. For the most part, this need is
satisfied by the `@babel/runtime/helpers/...` modules, which are also
defined in the `modules` package because they come from `node_modules`.
However, in the legacy bundle, `meteorBabelHelpers.sanitizeForInObject` is
used to fix buggy for-in iteration in older Internet Explorers.
Thankfully, this extra helper code does not need to be included in the
modern or server bundles, but only in legacy code.
