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
Recording process.versions allows us to be much more aggressive about
rebuilding binary dependencies whenever the version of Node/V8 might have
changed, even if the package was not just downloaded.
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 we pass a file to ImportScanner#addInputFiles, and a module identifier
resolves to that file, it shouldn't matter if the file actually exists on
disk. A common example is a new file generated by a compiler plugin.
Fixes#6767.
This is essentially the same treatment we give to compilation errors in
lazy files processed by Package.registerCompiler-style plugins, which
fixed a similar issue: #5998. Here are the relevant commits:
be986fd709ce4fda3783
We can revisit this conversion if it turns out anyone really wants to use
@import rules in CSS files instead of using something like LESS.
Part of #6037.
This in important optimization for #6037, and it also fixes#6627, since
we are now registering watchSet dependencies on the contents of
node_modules directories.
The most notable change here is that we now treat files in app imports
directories as lazy even before we know whether the app is using modules.
This could be a breaking change for some 1.3 apps that do not use modules
but have imports directories containing eager .js files. That (very minor)
level of backwards incompatibility seems acceptable in the context of
upgrading to Meteor ~1.3, however.
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.
Implements https://github.com/meteor/meteor/issues/6537#issuecomment-205954797
The setup.sh script was only sometimes written previously, so no existing
deployment logic should rely on it existing.
On the other hand, all apps built by `meteor build` require running
`npm install` in the programs/server/ directory, so the install hook I
added to programs/server/package.json will ensure npm-rebuild.js is
invoked reliably.
Using a pure Node script means this code will work just as well on Windows
as on Linux or Darwin, though Linux is by far the most common deployment
platform for Meteor apps.
TODO Remember to rebuild the dev bundle before the next release!
