Note that the value of the "main" property must include the ".node"
extension explicitly, because I have yet to encounter an npm package with
a native "main" module that omits the ".node" extension, and I am loathe
to start calling files.stat(id + ".node") uselessly for every single
missing module.
Fixes#7947.
Even though I think the fight is a bit futile, it is considered best practice to have newlines at the end of all files. At the request of meteor/meteor#7786, this commit adds newlines to the end of the new app skeleton `.gitignore` file. These skel files are used when generating new meteor apps so this avoids perpetuation of this problem into futrue generations. ;)
In an effort to beef up this PR, I also took the liberty of fixing the few other Meteor files which were lacking newlines (all `.gitignore` files)
Closesmeteor/meteor#7786
See #7495. Still some decisions to be made:
- Should we make --all-packages the default?
- How should we deal with *new* indirect dependencies?
- Should we do anything about underpinning indirect dependencies when updating?
This will make it much easier to fix bugs and make improvements going
forward, since they won't have to wait for the next release of Meteor.
One functional change: when the parent process exits, it no longer forces
all connected shell clients to disconnect, which is actually a more
convenient behavior, because it gives the clients a chance to reconnect
when/if the server starts up again, and it's easy enough to kill the
clients if that's what you want.
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.
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.
We no longer go to the trouble of generating source maps for files not
processed by compiler plugins, since that was slow and not very useful
(see ad3f56a0bf).
However, that means the test app and package that we use to test source
maps and stack trace rewriting need to use the ecmascript package in order
to behave as they did before that commit.
