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
`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
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.
`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
The default behavior meant that the launch screen would always be
released twice on a single hold: once when the template is rendered,
and once after a 6s timeout. So additional holds would not have any
effect beyond that timeout.
Importing meteor-node-stubs in a statically analyzable way is important to
ensure all the aliases for built-in Node modules get set up properly. This
does *not* mean that all meteor-node-stubs/defs/* modules will be imported
unconditionally.
Part of #6562.