When the babel-compiler package is processing files, it will now read
their package.json files looking for a "babel" section with "presets" or
"plugins" fields. If found, these presets or plugins will be appended to
the existing babelOptions.presets or babelOptions.plugins arrays.
Note that no other Babel options are currently supported, and the
"babel-preset-meteor" preset cannot be removed, though additional presets
and/or plugins can be added to it. This is by design: Meteor cannot
support your configuration it uses babel-preset-meteor, at least.
The preset and/or plugin modules listed in package.json must be installed
locally somewhere such that the given file can import them. If they are
top-level identifiers, they will be prefixed with "babel-plugin-" or
"babel-preset-", the same as Babel does it. Otherwise they will be
required as-is, so that you can implement your own Babel plugins locally,
rather than always using plugins installed from npm.
See the included tests for a concrete example.
Fixes#6351.
These changes allow Package.registerCompiler-style compiler plugins to
extract package.json and npm package information at compile time from the
files that the plugin processes.
This information was accessible before, but it certainly wasn't easy to
obtain it. These convenience methods should satisfy the motivation behind
Importantly, the files can now differ with respect to their .lazy
properties, which fixes#6806 and related issues. Note that the files must
have different .targetPath values if they have the same .sourcePath.
This is a minor breaking change for code that relied on module.id being
based on the .sourcePath instead of the .targetPath.
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.
