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.
Short-term fix for #10148.
Unfortunately, unlike most Meteor package and application code, which is
compiled after installation, Meteor compiler plugins are compiled before
they are published, so it's possible for a compiler plugin that uses the
ecmascript package to contain generated code that still uses the
module.watch API, instead of the new and improved module.link API.
A better long-term fix for this problem would be to compile compiler
plugins like any other Meteor code, using whatever version of the
ecmascript plugin the rest of the application is using.
