While not a Meteor bug, this makes the error message more helpful when a compiler tries adding an asset without data, as demonstrated in meteor/meteor#8034.
Thanks to suggestion by @sdarnell for this.
Closesmeteor/meteor#8034
If you call api.mainModule(path, where, { lazy: true }), that main
module will not be evaluated until other code imports it at runtime, and
won't even be bundled if no other code imports it.
Closes#6132.
This is a refinement of my previous commit 56c041c858.
The Meteor babel-runtime package does not provide substitutes for
babel-runtime/core-js/* modules, so we should not be discarding them from
the client bundle.
Fixes#7930.
The options.statOrNull function is not included in the JSON.stringify key,
but it affects the results because the implementation provided by the
ImportScanner relies on scanner._getFile to return fakeFileStat for
make-believe files created by the ImportScanner.
This becomes a problem if PackageSourceBatch#getResolver accidentally uses
a Resolver created initially for the ImportScanner, or vice-versa.
In particular, when a compiler plugin calls addJavaScript with a path
different from the original file path, the ImportScanner generates two
different modules, one of which imports the other. Only one of the files
exists on disk, though, so a special implementation of statOrNull is
necessary to keep the Resolver from having to share implementation details
with the ImportScanner.
When this system fails, users of compiler plugins see errors like this:
https://github.com/meteor/meteor/pull/7668#issuecomment-251976739
This speeds up both getPrelinkedOutput (because we don't spend any time
generating the identity source map) and toStringWithSourceMap (because we
don't have to combine those source maps).
We still generate line number comments for files without source maps, so
it's relatively easy to find the source line for a stack trace.
This is critical because it means Resolver objects can now survive
development server restarts, which means the optimistic Resolver#resolve
method can remember results indefinitely. Thanks to this change, the
Resolver#resolve method has practically disappeared from rebuild
performance profiles.
In addition to package.json files with "babel" sections, BabelCompiler now
supports .babelrc files, though in both cases only the "presets" and
"plugins" fields are respected. If a .babelrc file is found, package.json
files are ignored.
Additional presets and plugins are now *prepended* to the original
babelOptions.{presets,plugins} lists, so that the custom plugins have a
chance to handle syntax differently than babel-preset-meteor would.
The inputFile.getPackageJson method has been replaced by a more general
method, inputFile.findControlFile.
Fixes#6351.
Switching immediately to module.import and module.export for package code
would make it difficult for package authors to use Meteor 1.3.3 to publish
packages that still work in apps using older versions of Meteor. There's
nothing wrong with compiling import/export statements to module.import and
module.export in application code, however, because apps only need to work
with one version of Meteor.
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.
This path can be specified by calling addJavaScript({ path: ... }), and
defaults to being identical to the .sourcePath if no options.path is
provided. The .targetPath may be different from the .sourcePath when a
compiler plugin calls addJavaScript multiple times for the same file,
using a different options.path each time, e.g. when a JSON configuration
file turns into multiple JS resources.
If a Meteor package had a file called index.js, the runtime module system
would resolve "meteor/<name>" to "/node_modules/meteor/<name>/index.js",
instead of falling back to Package[<name>] as expected.
Installing a stub for Package[<name>] at /node_modules/meteor/<name>.js
means the runtime module system no longer needs the fallback, and will no
longer be confused by index.js files.
Fixes#6590.
