This should be a better fix for the problem I tried to fix with
479e505d71.
If we're going to be using compileOneFileLater by default, that's what we
should be testing in the compiler plugins self-tests.
The concept of a "root" file is specific to MultiFileCachingCompiler, so
we need to normalize it into a representation that makes sense to the rest
of the compiler plugin system.
Should help with #10014.
This enables using index.* modules with non-.js file extensions to make
the containing directory importable (cc @justinanastos):
c417044421
Since this is a core package patch update, you can update to this version
of the modules-runtime package by running
meteor update modules-runtime
This should give you modules-runtime@0.10.1.
This should be a better fix for the problem I tried to fix with
479e505d71.
If we're going to be using compileOneFileLater by default, that's what we
should be testing in the compiler plugins self-tests.
The concept of a "root" file is specific to MultiFileCachingCompiler, so
we need to normalize it into a representation that makes sense to the rest
of the compiler plugin system.
Should help with #10014.
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.
