According to traditional Meteor file loading rules, tests/ directories are
completely ignored: https://guide.meteor.com/structure.html#special-directories
However, if you specify a meteor.testModule in your package.json that
refers to a file inside a tests/ directory, Meteor should permit modules
to be loaded from tests/, as well as any modules that are imported by the
meteor.testModule entry point.
Fixes#9991.
Not including SockJS in the modern JS bundle was a nice bundle size
savings (28KB before gzip), but SockJS works better than a native
WebSocket for clients that are stuck in unusual networking situations, and
the fallback of using dynamic import() to load SockJS when the native
WebSocket failed was much slower than simply including SockJS in the
bundle and using it from the start.
Moreover, the new `meteor create --minimal` starter app does not use
socket-stream-client (nor DDP), so going back to including SockJS in both
the modern and the legacy bundles should have no impact on the minimal
modern bundle size.
If you want to continue using a native WebSocket instead of SockJS, you
can always pin the older version of the socket-stream-client package:
meteor add socket-stream-client@0.2.1
Now that compilation of compile-to-CSS files in imports/ and node_modules/
is actually lazy, we can safely call compileOneFileLater for all
inputFiles without worrying about accidental compilation.
If you're subclassing `CachingCompiler` or `MultiFileCachingCompiler`, you
can now implement a `compileOneFileLater` (emphasis on `Later`) to opt into
the new lazy compilation strategy.
If you implement this method, and `inputFile.supportsLazyCompilation` is
true, then the `addCompileResult` will not be called, though it is
probably a good idea to keep any existing `addCompileResult` methods, just
in case `inputFile.supportsLazyCompilation` is not truthy.
This will be an important part of a proper solution to the issues I
described (but failed to fix) in my broken PR #9968.
One limitation of Meteor's current compiler plugins system is that every
file we *might* use must be compiled before we know whether it *will* be
used by the application (which is something we only find out when we later
run the `ImportScanner`). More specifically, when inputFile.addJavaScript
is called, any information relevant to the current file must already have
been computed, even if the file will never be used.
This commit begins the process of supporting a lazy version of the
`inputFile.addJavaScript` method. For consistency, this interface is
supported by other methods like `inputFile.addStylesheet`, though it may
not make as much sense for non-JavaScript resources.
In this very basic initial implementation, the `lazyFinalizer` function is
called immediately, so that subsequent code can keep pretending that all
relevant information was eagerly provided.
The next step will be waiting to call `lazyFinalizer` until the last
possible moment, so that we can skip a potentially huge amount of
unnecessary compilation time.
A tweak to the change introduced in c4b5707747 to fix#9952.
This will allow clients that don't support the * value in `Access-Control-Allow-Headers`,
but do specify the `Access-Control-Request-Headers` (such as electron 2.0.2) to use dynamic import.
