Switch from Sass imports to Sass Module System

[inwardmovement]

Just putting this here, maybe for v5.

Sass Module System

[MartijnCuppens]

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.

[mocsy]

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

[MartijnCuppens]

@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.

[glen-84]

LibSass: sass/libsass#2807
Ruby Sass: EOL

[zackdotcomputer]

Just hopping in here to +1 this, especially since SASS used Bootstrap as an example for how the new package system could be used.

[jquense]

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!

[WraithKenny]

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.

[yaquawa]

I really need this +1

[ydmitry]

Highly need this for more advanced theming support

[ydmitry]

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

[MartijnCuppens]

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 sass/libsass#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?

[ydmitry]

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 sass/libsass#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]

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 sass/libsass#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?

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

[voltaek]

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.

[XhmikosR]

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.

[dgrammatiko]

@XhmikosR since the node-sass is officially deprecated ( https://github.com/sass/node-sass#node-sass ) could the team move forward with this one?

[ffoodd]

Already trying things out in #31728 and #31978 👍

[Platonn]

Hey @ffoodd
Thank you all Bootstrap folks for doing the great job of maintaining 2 major release versions: v5 and v4! In our project we still depend on Bootstrap v4.

Soon in October 2022 the @import will be deprecated and it will affect negatively both of those versions (as they heavily use @import inside) and all the projects that depend on Bootstrap v4 and v5.

Do you think you could switch from @import to use for both v5 and v4 and still keep both of the release versions alive? I'm aware that maintaining 2 major versions is a considerable work. So totally understand if you want to improve only v5.

Maybe switching to @use it's too much of a breaking change and it deserves a new major release? In that case, wouldn't you mind releasing new 2 lines of majors: v7 and v6 - which would be "compatible" successors of v5 and v4, respectively?

Many thanks!

[mdo]

The plan is to migrate in v6, we won't release two versions like that at the same time :). It is a breaking change and we can't do it until then.

[nex3]

Sass lead designer here! We've tried to design the module system to that it's possible to migrate a library to it without making that a breaking change, using import-only files with forwards to continue to expose the same APIs to existing @import users. For example, material-components-web was able to do this with minimal disruption.

The only really necessary breaking change is dropping support for Node Sass, but it's been deprecated for almost two years now.

[Supportic]

@nex3
Thank you for this feature but I quite don't understand how to use it in bootstrap context.
Say I have a project where I switched to @forward my styles into a final style.scss and @use all utils across the project. I would create a vendors/bootstrap directory and create 2 files.

|- sass
  |- style.scss    <- final sass file to compile
  |- core             <- class declarations
  |- utils              <- constants, colors ... to import with @use
  |- vendors
    |- bootstrap
      |- _bootstrap.import.scss
      |- _bootstrap.scss

_bootstrap.import.scss has the following content which forwards the file in the same directory:

@forward "bootstrap" as bs-*;

_bootstrap.scss has the following content which should override bootstrap !default variables and import the original library like mentioned here: https://sass-lang.com/documentation/at-rules/import#configuring-modules-through-imports

// prefixed like forwarded in the import file
$bs-container-max-widths: (
    md: 750px,
    lg: 992px,
    xl: 1000px,
);
$bs-container-padding-x: 15px;

@import "../../../assets/bootstrap5/bootstrap";

The question is how do I use bootstrap mixins now inside my core directory where I define my own styles. I tried it this way but without any results.

@use "../vendors/bootstrap/bootstrap" as bs;
h1 {
    font-size: 1.4rem;
    @include bs.media-breakpoint-up(md) {
        font-size: 3rem;
    }
}

Edit: solved it by modifying my style.scss as following and accessing mixins like described above.

@charset "UTF-8";
@forward "vendors/bootstrap/bootstrap";
@forward "core";

Extending bootstrap classes: unfortunately stylelint doesn't like it when you extend classes directly, instead you should use %placeholders (stylelint rule) which are regular class defintions but doesn't render in the final .css. Here it's different since we want those bootstrap classes to have available in our final .css.

@use "../vendors/bootstrap/bootstrap" as bs; // doesn't require a namespace
h1 {
    @extend .fs-1;
}

[Eireternal]

Hi all, I'm a bit confused. From everything I've seen, @import is currently deprecated and on Octoober 2022, it will no longer be supported. Is this no longer the case?

Secondly, if this is true how can our apps utilizing the both bootstrap and sass packages? Wouldn't we be dead in the water?

[kfriend]

@Eireternal the latest update on the @import deprecation, that I can find:

July 2022: In light of the fact that LibSass was deprecated before ever adding support for the new module system, the timeline for deprecating and removing @import has been pushed back. We now intend to wait until 80% of users are using Dart Sass (measured by npm downloads) before deprecating @import, and wait at least a year after that and likely more before removing it entirely.

Found this at the bottom of https://sass-lang.com/blog/the-module-system-is-launched

[masi]

@import being deprecated or not, Dart SASS has all the new features. The SASS team made it quite clear that only the Dart version will be enhanced over time.

In my own experience switching to Dart SASS from other versions was painless. I hope so that it has been the case for others. So making Dart SASS a requirement for Bootstrap v6 is IMHO sensible.

[noahgregory-basis]

Is there any sort of update on this? Sass is moving forward on deprecating @import. sass/sass#3513

[julien-deramond]

For now, we'll try to stick to the original plan: in v6

• dropping retro-compatibility support with Node Sass
• switching to the new Sass major version + using module system

Depending on when the deprecation of imports is released in Sass, we'll maybe introduce modules sooner in an intermediate v5.X if necessary, but it's more of a backup plan for now IMO

[bastienmoulia]

A first step could be to enable dart-sass in Hugo, because by default it use lib-sass.
And also moving/changing some of the SCSS functions that use variables in another place to avoid loop of @use.

[dailytabs]

5 years later, the hammer hits; and, it's still not upgraded? At the very least, can we get a v6 label (so it shows up on search)?

Already had to wait for ng-bootstrap and Angular 19, now this? At what point do I give up on bootstrap?

Yes, Angular Material does not suffer from the same issues as Bootstrap 5.3 with Dart Sass.

Angular Material has already transitioned to the newer Sass syntax that uses the @use rule, so it is not affected by the same Dart Sass issues that Bootstrap 5.3 experiences.

[travispaul]

When following the customization guide on the website, numerous sass deprecation warnings are thrown about this:

DEPRECATION WARNING [import]: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.

[mitcoding]

Since I just tried removing all @import usage on the sites i work on. I would like to add to the discussion something TWBs will need to consider if they haven't already, as well as give some clarity to those asking why it's take so long for TWB to migrate.

The biggest issue I ran into is the fact that the new Module pattern only lets you configure the variables once, using either @forward with() or @use with(), and this must happen before before any plain @use imports are used if the variables are shared in another module. This the equivalent limitation of @import in that you had set the variables you wanted to customize before you @imported the file you wanted to customize.

This particular problem though is made worse due to the current structure of the sass Variables in bootstrap, that heavily rely on reusing sass variables to set other related sass variables or (even css variables) (e.g. the two biggest being $utilities, $theme_colors, etc) and it's reliance on these shared variables in modules like _functions.scss.

This ends up creating a Chicken and Egg Problem if you want to use a boostrap function in _functions.scss to override defaults like $success, $primary, etc and then have their customized values used by the sass variables $theme-colors, and/or $utilities.

In the new @use model and bootstrap's current variable structure you are forced to manually update $theme-colors and/or $utilities with map.merge after you customize a bootstrap sass variable, which due to the shear amount of sass variable reuse in Utilities is prone to miss errors due to shear size of the $utilities variable. not only that you would have to also manually update all the sass variables that also consume the sass variable you customized.

This can be worked around to some extent with the older @import model because the amount of global variables required for _functions.scss to work correctly was minimal, which allowed you to use those functions in your customized bootstrap variables before you imported _variables.scss.

It is due to this chick and egg problem I'm not able to remove @import usage for twbs in my sites but have been able to remove its usage in all my other use cases (was able to remove ~1000 @imports and is now left with only 6 @imports for twbs, as it was needed to work around the issue described above until I have time to refactor my code to remove the issue described above).

[nex3]

(Worth noting that the Sass team has been working directly with the Bootstrap team to do this migration, but personal lives and holidays have made progress slow recently.)

[julien-deramond]

Hey there,

Several issues have been opened in our repository related to recent Sass deprecation warnings, as well as the transition from Sass imports to the Sass module system, such as this one. Except if I'm wrong, these issues are interconnected: addressing the deprecation warnings requires using and adopting the Sass module system, which involves refactoring the code and updating the Hugo configuration to fully support Dart Sass.

I’ve started working on it in this pull request, though it’s still in a very early draft stage. Apologies for the delay—I’ve been away for about a month due to personal matters and holidays. I’ll pick this back up as soon as I can. I know the wait can be frustrating, and I appreciate your patience.