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.
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.
@pagesrichie These changes will be available starting in 1.7.1-beta.1, which should be published in the next half hour or so.
As long as packages and application code are compiling
In general, we merge PRs into
I just saw the METEOR@1.7.1-beta.1 release on the https://github.com/meteor/meteor/releases page. I will go ahead and update my meteor and hopefully it fixes the issue with https://github.com/Semantic-Org/Semantic-UI-Meteor files compilation!
And @benjamn yes that package is dependent on the meteor core less package. So I will try it out with this new meteor release and let you know.
@benjamn Not sure where to post this.. but there's an issue with the 1.7.10beta.2 release, getting an error here when the less package is enabled when I have my less files in the client dir, i even disabled semantic-ui package and if it has any less files to parse it crashes. (To re-enact, I added all my semantic-ui client files somewhere inside the client dir and then then simply enable less package or the firstname.lastname@example.org package (that automatically got upgraded to when upgrading to this meteor release, and it just crashes with the following error):
TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
@pagesrichie In general, the best place to post it would be in a new issue. Though you're right in your identification of this issue as a suspect.
The problem stems from this code:
...and a result of
I suspect that
...possibly because of a compilation failure or potentially just because of a completely empty file (I'm not sure what
We should probably guard against this within this
I'll defer to @benjamn since this is fresh on his mind.
@pagesrichie @abernix That problem should be fixed by #9998. In short, we were applying the CSS source map to a JS module that dynamically appended the CSS to the
When I implemented support for the "module" entry point in package.json files for client code in #10541, I modified PackageSource#_findSources to include files found in node_modules that need to be compiled, but my implementation considered only "local" node_modules directories, like the one in the application root directory, while neglecting the private .npm/package/node_modules directories that many Meteor packages have. This commit includes .npm/**/node_modules when _findSources is scanning a Meteor package, which should solve issues like #10544, where a Meteor package imports an npm package that was installed with Npm.depends, and that npm package has a "module" field in its package.json file, pointing to an ESM entry point module, but the ESM syntax was not appropriately compiled, leading to parse errors like "Unexpected token export". Before lazy compilation was introduced in Meteor 1.7 (#9983), including the node_modules directories of Meteor packages would likely have been a big problem for build performance, since there would be that many more modules to compile. It's still worth making sure this change doesn't regress build performance for other reasons, but I'm reasonably confident lazy compilation will save us here, unless there are just too many npm packages installed via Npm.depends that export ESM modules.