Upgrade a large project to Nuxt 2.0.0.
Fast hot reload
After updating the project to nuxt 2.0 hot reload started to work very slowly. At any change, the sass-loader processes styles in all .vue files. It takes more than 30 seconds.
Yeah, I've started to get same issues recently, especially on relatively big vue files (+100 lines of code). It sometimes takes more than a minute to recompile and sometimes the process just shut down with a memory overflow error
Still up to date. Sass is re-processed in all files even if the change did not affect the styles at all.
Is it possible to do a partial recompile of only those parts that were changed?
Running nuxt dev
it takes 102s before the app become available.
sass-loader is extremely slow, we are customizing element-ui sass variables and using a theme.
After digging through a lot of material I don't see much we can do. sass-loader
does not cache imports/partials and will recompile everything. You could try https://github.com/yibn2008/fast-sass-loader or enabling the experimental options parallel
and cache
(https://nuxtjs.org/api/configuration-build#parallel).
Also things like sourcemap
compilation slows down the build as well.
After digging through a lot of material I don't see much we can do.
sass-loader
does not cache imports/partials and will recompile everything. You could try https://github.com/yibn2008/fast-sass-loader or enabling the experimental optionsparallel
andcache
(https://nuxtjs.org/api/configuration-build#parallel).Also things like
sourcemap
compilation slows down the build as well.
But why did it work much faster before nuxt 2.0?
@LordGuard That's hard to tell without a reproduction repository :frowning_face:
We have successfully removed sass-loader from Nuxt and using fast-sass-loader instead, our build went down from 102s to 42s.
Here is the code to replace sass-loader with fast-sass-loader in nuxt.config.js
// Replace all occurences of sass-loader with fast-sass-loader as Nuxt keep
// use both during the build
config.module.rules = config.module.rules.map(rule => {
// sass-loader is only inside "oneOf" attribute
if (!rule.oneOf) {
return rule;
}
const newRule = rule;
newRule.oneOf.map(r => {
if (!r.use.some(l => l.loader === 'sass-loader')) {
return r;
}
const newLoaders = r;
newLoaders.use = newLoaders.use.reduce((loaderAcc, loader) => {
if (loader.loader !== 'sass-loader') {
return [...loaderAcc, ...[loader]];
}
return [...loaderAcc, ...[{
loader: 'fast-sass-loader',
options: loader.options,
}]];
}, []);
return newLoaders;
});
return newRule;
});
@Atinux @manniL will this code be added to Nuxt official code at some point? I think 50% speed boost is worth switching
I will try fast-sass-loader on a project afternoon. If it really worth, we can write an official module 😊
@pi0 Something in the style of https://github.com/Developmint/nuxt-svg-loader comes to my mind. I guess I'll create one 🙊
Be careful fast-sass-loader
have issues with custom aliases using Nuxt such as @
or $
but work well with the default ~
.
There is already a lot of issues on fast-sass-loader repository about it.
@XavierLeTohic in scss/sass files $
should be reserved to defining a variable so I don't think there is any possibility to use it for Nuxt specific purposes. Speaking about @
it's also reserved for css @ rules so it won't be available inside scss context. The only place it's used by Nuxt is inside js imports afaik so I don't think it's a show stopper
Yeah sorry it was just an example, I forgot that case with sass. I should have say "With any custom aliases"
@pi0 any updates on this one?
Guys, I've came across very disturbing issue. It's related to using build.styleResources
option that built into Nuxt. When it's enabled all dependent sass modules are being recompiled twice on every change even if the change happened in some unrelated js file. In my project I have quite a lot of resources I need to inject into Vue files so just give you some numbers.
build.styleResources
- off
: hot reload time 1 sec
build.styleResources
- on
: hot reload time 1 MINUTE
Although when I use plugin with similar functionality nuxt-sass-resources-loader build speed is back to normal with the same setup
I plan to add a separate bug about this, but just wanted to drop it quickly here because I think this stuff is related to the problem described in the current issue
@XavierLeTohic I tried your config with fast-sass-loader
but I didn't notice any significant build speed increase. For my project it was even slower, 49s - sass-loader
50s - fast-sass-loader
(though I also have a lot of SCSS assets)
What I did notice is that your config doesn't play nice with nuxt-sass-resources-loader
, maybe because it also uses sass-loader
I'm getting
Error: Mixin transition is missing argument $transition-time.
from building Bootstrap default assets
Has there been any progress in this matter?
Is it possible to do a partial recompile of only those parts that were changed?
This would definitely be the better option. To be honest, I went back to picking Laravel in a recent project solely because of how frustrating the wait is. Having to wait 20-30 seconds _every time you save_ is a huge deal breaker.
What are the alternatives we can use as of now?
Hey folks! :wave:
For anyone having problems, could you please:
yarn build --profile
(or the npm equivalent) and drop the stats in here?@manniL
Some times when i save in dev it takes 2.30 min to save !!
Here is my build stats
Stats by Ext
| Ext | Requests | Time | Time/Request | Description |
|-------|----------|-------|--------------|----------------------------|
| js | 223 | 757ms | 3ms | JavaScript files |
| vue | 2582 | 16s | 6ms | Vue Single File components |
| css | 43 | 337ms | 8ms | css files |
| styl | 9 | 1s | 126ms | styl files |
| eot | 36 | 12ms | 341μs | eot files |
| woff | 11 | 796μs | 72μs | woff files |
| woff2 | 11 | 874μs | 79μs | woff2 files |
| ttf | 11 | 213ms | 19ms | ttf files |
| svg | 40 | 23ms | 578μs | svg files |
| Total | 2966 | 18s | | |
Stats by Loader
| Loader | Requests | Time | Time/Request | Description |
|------------------------|----------|-------|--------------|------------------------|
| babel-loader | 821 | 2s | 3ms | Babel Loader |
| vue-loader | 4238 | 31s | 7ms | Vue Loader |
| vue-style-loader | 171 | 69ms | 405μs | Vue Style Loader |
| css-loader | 844 | 14s | 16ms | Css Loader |
| postcss-loader | 844 | 14s | 16ms | Postcss Loader |
| pug-plain-loader | 606 | 2s | 3ms | Pug Plain Loader |
| stylus-loader | 793 | 13s | 17ms | Stylus Loader |
| style-resources-loader | 793 | 13s | 17ms | Style Resources Loader |
| url-loader | 109 | 250ms | 2ms | Url Loader |
| Total | 9219 | 1m | | |
Hash: e55ce7f2580becbca517
Version: webpack 4.20.2
Time: 20755ms
server-bundle.json 12.8 MiB [emitted]
Entrypoint app = server-bundle.js
✨ Done in 83.09s.
@melrefaie so in your case when u save in dev its longer than build? if so - do u have a component\page with a lot of nested tags?
@manniL I'm not able to share the code but the use case is pretty simple:
I have a _variables.scss file which I need to load on a bunch of components in order to get access to scss vars like $dark, $light, $header_gradient, etc.
I can do so manually (include + full path) or use something like sass-resources-loader
Every time I save a file, npm run dev
seems to recompile those scss dependencies on EVERY file, which is silly in most cases (i.e. I'm saving nuxt.config.js and it starts rebuilding all my .vue components)
in your case when u save in dev its longer than build?
Yes it takes longer time than build.
I don't have a lot of nested tags. but i have:
186 pages
75 component
I don't face this problem with small projects. but in large projects its nightmare to work with .
in large projects its nightmare to work with
@melrefaie Is your issue similar to mine? Are you injecting SCSS into those components?
@melrefaie Is your issue similar to mine? Are you injecting SCSS into those components?
@sergiocastrovale
I inject stylus in layouts, i use
Most helpful comment
I will try fast-sass-loader on a project afternoon. If it really worth, we can write an official module 😊