Because the files are in an imports/ directory, they are still considered
lazy, so they will not be applied to the document unless imported from JS.
Related: #6037
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.
`Match.Optional` is still only supposed to "pass" if the value is `null`
or the specified type. The new `Match.Maybe` allows `undefined` or
`null` in addition to the specified types. `Match.Optional` is on the
track toward deprecation, however to not break existing code it was
*supposed* to stay working the same as before. (per #3876).
There weren't tests in place to make sure that `Match.Optional` kept
working the same, and the code didn't actually make it keep working the
same. Hopefully extra tests will make this better.
`.Maybe` has some additional bugs, but should be addressed separately
(see #6271)
Fixes#6735
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.
