Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The SASS @imports are organised on folder level now, so globbing is no longer needed.
Also it can boost the sass compiling runtime by up to 1500% and probably even more in projects that use imports all-over. But, it could also be considered as bad practice ... here an article explaining mixin vs. include.
I would vote for removing, what do you think?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | remove-not-used-node-libs-3045550-7.patch | 6.22 KB | pivica |
Comments
Comment #2
ytsurkComment #3
pivica commented+1 from my side, make sense we remove this.
Related to optimization improvements i've just created #3045552: Evaluate pnpm package manager, what do you think?
Comment #4
pivica commented> But, it could also be considered as a bad practice ... here an article explaining mixin vs. include.
Read the article, i can't figure out how it is related to this issue, but this part is interesting:
This would mean that it does not matter if we are grouping media queries or not, which is related to #3042171: Decide what to do with css-mqpacker npm package is not maintained any more which would mean we can remove css-mqpacker, right?
Comment #5
ytsurkYeah, the article is about media queries and imo we can also strip mqpacker.
But it's also about mixins vs. imports. In this project where I use a lot of imports, i'm thinking of moving to mixins .. this will reduce the possibility for mixups caused by vice-versa imports and also make it again compile faster also with globbing.
Comment #6
pivica commentedSorry, i don't follow any more fully.
> But it's also about mixins vs. imports. In this project where I use a lot of imports, i'm thinking of moving to mixins ..
Not sure what do you mean here. Using fewer imports and use mixins instead? Can we get some high-level code examples of how this would work?
> So the question here is, do we support "globbing" (using import paths with /**/ et al), or force per file/folder imports?
Originally this issue is about "globbing is no longer needed.". Not sure why this question here now?
We do not use globing at all and it is fine we remove it in base themes. If some custom project wants to use globbing its free to add it on custom level i guess. Does this make sense?
Comment #7
pivica commentedOur generator workflow and sass inheritance would probably not like using of gulp-sass-glob. So this and the fact that we are not using it means we should definitely remove it.
While working on this i figured that there are additional node libraries that we are not using. Here is a full list of libraries that are removed:
- eslint
- gulp-cached
- gulp-changed
- gulp-if
- gulp-notify
- gulp-sass-glob
- gulp-svgstore
- gulp-uglify
- node-sass-import-once
- postcss-scss
- pump
All in total, with dependencies, this is 85 libraries that are removed. I've measured compilation time before and after this change for complex client theme and compilation times are more or less the same - no measurable speed improvements.
Comment #8
ytsurkNot so in topic, but it's good to remove unused dependencies.
Sad, that there is no performance boost :(
Maybe I can give it a try, but I do not promise ..
Have good Rauhnächte BTW!
Comment #9
pivica commented> Have good Rauhnächte BTW!
Thx :)
Comment #11
pivica commentedCommitted.