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`.
