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!
In particular, it is very important that the 'modules' package qualifies
as using itself, or else its require function will not be able to find
files unless they are mentioned in package.js.
Fixes#6673
The Meteor "dev bundle bin commands" which proxy through to the
meteor version of npm/node was not returning the exit code from the
command which it executed. This creates problems for things like
`meteor npm run script-name` when the exit code is important. This
comes into play when you run npm scripts which run tests, lint code, etc.
This fix causes the meteor-tool to process.exit with the spawned process
exit code.
Windows Disclaimer: I used the same flush-buffers-on-exit-in-windows
that the tool/cli/main.js uses because I would assume the same problem
exists, however, I don't have the Windows environment to test or confirm
that this code works at all.
Also, couldn't find any tests that directly tested this dev bundle
bin-command passing scenario (though hard to search through them all),
so I created a barebones test app and tests.
Building the iOS app for release should be done from Xcode anyway, to
correctly code sign and submit to TestFlight or the App Store.
Because building would override `build-extras.xcconfig`, this would
remove a temporary workaround for #6492, which is now correctly applied
on both `meteor run` and `meteor build`.
