Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to improve build performance #276

Open
lorensr opened this issue Jul 11, 2018 · 5 comments
Open

How to improve build performance #276

lorensr opened this issue Jul 11, 2018 · 5 comments

Comments

@lorensr
Copy link

lorensr commented Jul 11, 2018

According to METEOR_PROFILE=1 meteor run, my app takes 30 seconds to rebuild with this package and 22 seconds without it. Is there any way the performance can be improved? Either in the package code, or by my use of it? Right now I'm doing individual-component JS imports, eg import './Post.scss' inside /imports/Post.js. Would it be better if I moved all my SCSS into one file, or if I switched from JS imports to SCSS imports? (@import '{}/imports/Post.scss' inside client/styles.scss)?

meteor version: 1.7.0.1

fourseven:scss version: 4.9.0

@sebakerckhof
Copy link
Collaborator

It might be because you have a lot of scss files in your node_modules which get compiled unnecessary. Could you try if it's better with meteor 1.7 instead of 1.7.0.1? If so, that's because there was an optimization for this in 1.7 that had to be reverted and will be re-introduced in 1.7.1.

Other than that I don't think there's much we can do since we already use meteor's caching system and basically just pass the files to node-sass which uses libsass and is already the fastest way.

@lorensr
Copy link
Author

lorensr commented Jul 11, 2018 via email

@sebakerckhof
Copy link
Collaborator

in 1.7.0.1 it's all of them. Meteor 1.7.1 will have an optimization to only compile the once you import. See: meteor/meteor#9983

@sebakerckhof
Copy link
Collaborator

Meteor 1.7 also only uses the once you import, but using another technique which fails in some scenarios. Hence why 1.7.0.1 was introduced to revert this optimization.
If you don't experience any build errors, it's safe to stay on 1.7 until 1.7.1 is released.

@macrozone
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants