Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
In Meteor 126.96.36.199, multiple developers noticed that the
The original reason for this architecture was that existing build plugins widely used by the community were accustomed to receiving a complete batch of all the files they needed to process, up front, all at once. This was especially important for compiler plugins that support importing other files of the same type, such as
By contrast, any system that attempts to scan the dependency graph of an application needs to be able to compile one file at a time. Most recently, I was reminded of this limitation when #9968 did not work, because my attempt to skip compiling
For a long time, I thought these two approaches were irreconcilable. Either Meteor would have to maintain backwards compatibility despite the performance cost, or we would have to overhaul the compiler plugin system and deprecate existing plugins.
As this PR demonstrates, it turns out we can have it both ways. When calling
Here's what that looks like in the
In other words, compiler plugins still receive a complete list of all files they should process, in case they depend on that behavior, but they have the option of postponing costly compilation until later.
Note that the compiler plugin system has the freedom to invoke the callback as soon as it likes (even immediately, as I initially implemented it, just to check my sanity), though in practice the
As a demonstration of the impact of this change, here's a fresh build of a new
and here's the same profiling output with this optimization enabled:
If you do the math, the average time per file is
If you're a compiler plugin maintainer (cc @sebakerckhof @GeoffreyBooth et al), please take note of this new API, and especially the
If you're an application developer, you won't see these benefits until you update to Meteor 1.7.1, but we hope this gives you an additional reason to help test the next 1.7.1 beta release.
Jun 13, 2018
19 checks passed
referenced this pull request
Jun 13, 2018
@benjamn Hi Ben, thanks for this pull - due to the way meteor compiles LESS, my semantic ui meteor (https://atmospherejs.com/semantic/ui, https://github.com/Semantic-Org/Semantic-UI-Meteor) LESS files takes 8-10 seconds upon every time I reload a page - even when I change a single line of text in my app completely unrelated to the css itself! I've realized its not a fault with the semantic ui package itself but with the way meteor compiles/reads all the LESS files upon every change.
I came across this post and read it - a little confused on a few parts -
Thanks for looking into this important issue and looking forward to a response.
@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 email@example.com 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.
referenced this pull request
Jun 14, 2018
@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