Bootstrap: Switch from Sass imports to Sass Module System
Just putting this here, maybe for v5.
inwardmovement
All 17 comments
AFAICT, the module system only works in Dart Sass, not in ruby Sass or Lib Sass. Since the majority of build systems won't support this yet, I guess it won't be a good idea to switch now.
MartijnCuppens
on 14 Dec 2019
What are the 'majority of build systems' you mention?
I had no problems with webpack, parcel nor gulp using the sass package.
Maybe the right approach would be to migrate from node-sass to sass first.
The module system comes as a free bonus with the migrator anyway.
That might clear these warning from my build logs as another added bonus:
WARNING: You probably don't mean to use the color value indigo in interpolation here.
It may end up represented as indigo, which will likely produce invalid CSS.
Always quote color names when using them as strings or map keys (for example, "indigo").
If you really want to use the color value here, use '"" + $color'.
â•·
4 │ --#{$color}: #{$value};
│ ^^^^^^
╵
node_modules/bootstrap/scss/_root.scss 4:9 @import
node_modules/bootstrap/scss/bootstrap.scss 11:9 @import
mocsy
on 16 Dec 2019
@mocsy, node-sass is used more to compile sass, see https://npmcharts.com/compare/sass,node-sass?interval=30
Other than that, we have a list of other compilers using LibSass: https://sass-lang.com/libsass
Even if we switch to sass instead of node-sass (which we might do at some point), we still need to support node-sass as long as it is not deprecated.
MartijnCuppens
on 16 Dec 2019
LibSass: https://github.com/sass/libsass/issues/2807
Ruby Sass: EOL
glen-84
on 25 Dec 2019
Just hopping in here to +1 this, especially since SASS used Bootstrap as an example for how the new package system could be used.
zackdotcomputer
on 24 Apr 2020
The event horizon for node-sass supporting the new module system seems like 2-3+ years, it's already many months behind libsass which seems like it's slating impl for a major release tentatively in 2021? I'd love to see Sass modules used in bootstrap, but it does seem like there needs be either a cultural shift from using libsass or an influx of new contributors to help speed up implementation. Seems like web-devs wanting to do c++ development is a fairly niche subset!
jquense
on 19 May 2020
Why not leave 4.5 as libsass compatible, and make 5 dartsass...at least until libsass updates itself (if ever). Backwards compatibility makes no sense here.
WraithKenny
on 21 Jul 2020
I really need this +1
yaquawa
on 8 Aug 2020
Highly need this for more advanced theming support
ydmitry
on 25 Aug 2020
https://github.com/sass/sass/blob/master/accepted/module-system.md#timeline - @import directive will be deprecated in Oct 2021 and dropped support in Oct 2022
ydmitry
on 11 Sep 2020
Current (September 2020) monthly node-sass installs: ~ 20.7 million
Current (September 2020) monthly sass installs: ~ 9.6 million
Current (September 2020) module system support in node-sass: not supported (see https://github.com/sass/libsass/issues/2807)
On the other hand, if we stick to @import, Bootstrap won't work anymore for the latest sass version from Oct 2022. Not sure what to do here, any thoughts @twbs/team?
MartijnCuppens
on 11 Sep 2020
SASS language has one specification it's not depend on if it is libsass, ruby sass or dart sass. It can be deprected in 2021 for dart sass and e.g. in 2022 for another implementation if it will be existing (I mean import will be deprecated in future in other implementations too). Regarding libsass which is used by node-sass - it will be deprecated https://github.com/sass/libsass/issues/3123 as well. So if ruby-sass is deprecated and node-sass is deprecated we actually will have only one implementation.
As an option it can be like it was done for SCSS and LESS - two folders with SCSS with "import" directives and another folder with new "use" directive. As a first step maybe use migration tools and try to do it automatically: https://sass-lang.com/blog/the-module-system-is-launched#automatic-migration
ydmitry
on 12 Sep 2020
Current (September 2020) monthly
node-sassinstalls: ~ 20.7 million
Current (September 2020) monthlysassinstalls: ~ 9.6 million
Current (September 2020) module system support innode-sass: not supported (see sass/libsass#2807)On the other hand, if we stick to
@import, Bootstrap won't work anymore for the latestsassversion from Oct 2022. Not sure what to do here, any thoughts @twbs/team?
I wouldn't make decision based on statistics, becuase mostly sass implementation and version is selected by frameworks. When frameworks will remove node-sass and add dart sass this statistics will be changed very quickly. E.g. Angular already switched to dart sass from node-sass in Angular 8
ydmitry
on 12 Sep 2020
Aside from wanting to move away from imports, more importantly the Sass team is in the process of deprecating "LibSass and the packages built on top of it, including Node Sass". Their project to do so is here with issues discussing the move linked in it (the source of my quote). I think it would be a smart move to swap out node-sass in the build pipeline for sass before we finalize Bootstrap v5.
According to the sass npm package doc (which uses Dart Sass, which is up-to-date with the Sass spec and thus supports imports), it should be a mostly drop-in replacement for the node-sass package. Looking over the command arguments we use for node-sass, the only issue that sticks out to me is 'precision' is defaulted to 5 and seems like it can't be configured. We currently use a precision of 6, but with our supported browsers changing greatly from Bootstrap v4, I'm not sure that a precision of 6 is still necessary, anyways. The sass doc for the precision param says "Dart Sass defaults to a sufficiently high precision for all existing browsers, and making this customizable would make the code substantially less efficient."
The most recent issue I could find on precision is here, and a quick test of setting the width of an element in Chrome (on Windows Server 2019) to 599.99999px or 600.00001px both show 600px in the dev tools box model diagram, as @MartijnCuppens was testing in the issue, so hopefully that concern is also no longer an issue.
voltaek
on 14 Sep 2020
We already test dart-sass on CI https://github.com/twbs/bootstrap/blob/main/.github/workflows/dart-sass.yml
They use a fixed 10 digit precision which might be too much. For the minified files, we can bring it down to 6 or whatever, but for the normal files, it will be 10. That being said, that's not a real issue TBH. The real issue is how we are going to catch breakage. I guess we could just test node-sass on CI and switch to sass. That's doable.
XhmikosR
on 14 Sep 2020
@XhmikosR since the node-sass is officially deprecated ( https://github.com/sass/node-sass#node-sass ) could the team move forward with this one?
dgrammatiko
on 27 Oct 2020
Already trying things out in #31728 and #31978 :+1:
ffoodd
on 28 Oct 2020
Related issues
ziyi2
·
3Comments
steve-32a
·
3Comments
leomao10
·
3Comments
fohlsom
·
3Comments
MrCsabaToth
·
3Comments
Most helpful comment
Why not leave 4.5 as libsass compatible, and make 5 dartsass...at least until libsass updates itself (if ever). Backwards compatibility makes no sense here.