Sass deprecation warning: Using `/` for division is deprecated

[btakita]

dart-sass has deprecated / in favor of math.div. Compiling https://github.com/twbs/bootstrap/blob/main/scss/_variables.scss now results with many sass warnings.

368 │ $navbar-padding-horizontal:        floor(($grid-gutter-width / 2)) !default;
    │                                           ^^^^^^^^^^^^^^^^^^^^^^
    ╵
    node_modules/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss 368:43  @import

DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0.

Recommendation: math.div($grid-gutter-width, 2)

More info and automated migrator: https://sass-lang.com/d/slash-div

[ralphjesy12]

Same issue. Builds now crashing because of warnings.

[Acmion]

Same issue.

Especially annoying since you can not "mute" sass warnings. This is a problem with Sass and not Bootstrap, but still affects the user experience.

[XhmikosR]

@ffoodd I just hit this in the npm starter project with sass 1.33.0. Now, it is a warning only, but it's annoying because it's repeated many times. My understanding is that the proposed methods don't work with node-sass which is OK for v5.0.0, but for v4 we need to think about it... I was planning to switch to sass in v4 too but perhaps we should do it in a minor version bump.

PS. I run dependabot so that we get the updated PR and see the warnings.

EDIT: https://github.com/twbs/bootstrap/pull/34057/checks?check_run_id=2636494233#step:6:12

[lothargrieb]

Same problem here... hopefully not to much work for the boostrap team.

[Onefivefournine]

Hope that the team will fix it soon! I am now unable to start dev build because of huge amount of warnings.

Guys from sass refuse to add any silencer for warnings, because they think that warnings are critical, and you should never silence them, even if there are 100k warning lines in your dev build. https://github.com/sass/libsass/issues/2822#issuecomment-482914373

UPDATE: Solved by manually downgrading sass to 1.32.*

[vbarden]

UPDATE: Solved by manually downgrading sass to 1.32.*

Can confirm downgrade works.

Thanks @Onefivefournine

[jeremy-holt]

I'm using gulp-dart-sass. How would I downgrade to sass 1.32 (I don't think gulp-dart-sass uses sass)?

[XhmikosR]

Please everyone stop spamming the issue. We will find a solution for v5. You should bug though the Sass devs to allow to hide these warnings. IMHO it's pretty bad right now.

[apolopena]

See https://github.com/sass/dart-sass/issues/1319

[vinorodrigues]

sass/dart-sass has released v1.34.0 that adds a --quiet-deps flag. Amend this to package.json, line #26 under "css-compile"

• --quiet-deps still has warnings, but not so many (recommended)
• --quiet gets rid of all the warning, but may not be a good idea

[viewerzhang]

很无语

[bram-pkg]

@exeptionerror has been spamming the same link already 5 times or something.

[mmarton]

"solution"... by fixing sass compiler to an older version...

a solution would be something like a polyfilling math.div() for node-sass and replaceing it everywhere in the code

[ffoodd]

Polyfilling isn't an option IMHO, this is simply not compatible. The best way I can think off for now is to add a new dedicated function for div() —just like we already have add() and subtract()— and ensure every division uses it in our core. Then anyone willing to use latest Dart Sass could just change this function to use math.div. We may even add this variant in our core, without including it in our default build.

AFAIK there's no way to either check for @use support nor switch code depending on compiler, so the best we'll be able to do is to facilitate using one or the other on dev side.

Any thoughts or ideas are welcome, obviously!

[ngekoding]

Hope that the team will fix it soon! I am now unable to start dev build because of huge amount of warnings.

Guys from sass refuse to add any silencer for warnings, because they think that warnings are critical, and you should never silence them, even if there are 100k warning lines in your dev build. sass/libsass#2822 (comment)

UPDATE: Solved by manually downgrading sass to 1.32.*

Thanks, solved for Element Plus also.

[e200]

Just update your sass version to exatcly 1.32.13

[vince7488]

Downgrading may be a trick that works, but it's bad advice and definitely not the real solution.

The real solution is actually posted on the SASS warning on the terminal.

Recommendation: math.div($grid-gutter-width, 2)

full solution:

@use "sass:math";   //Normally placed on top of your scss file

div.sample {
     width: math.div(100%, 2);
}

So the bootstrap team needs to work on changing every instance of slash operators in the framework.

[ffoodd]

That won't happen soon, as it'd break Libsass compatibility, as stated above.

[apolopena]

Libsass is depricated, time to cut the cord?

[bram-pkg]

What would be the deprecation plan for libsass in Bootstrap?

On Fri, May 28, 2021, 22:27 Apolo Pena @.***> wrote:

Libsass is depricated, time to cut the cord?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/twbs/bootstrap/issues/34051#issuecomment-850653896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFQHIY6KXMKOS5HT7RHB43TP74DNANCNFSM45IGGYFA .

[shehi]

You guys just released 5.x - better get rid of LibSass at this point, before it gets too late.

[alpadev]

Please people, calm down.. You need to understand that it's less about us but rather that we care about our users.. The situation is completely awkward for us too, because we try as much as possible to support both, libsass and dart-sass, so not to breake people's setup.

The Sass team decided to deprecate the default way of doing division, without providing a real option to do this in a graceful way. Considering that a lot of setups broke because of those warnings.

Like @ffoodd pointed out already, in theory, there would have been the possibility to script around this problem by adding necessary functionality into the language upfront. However, at this point we're still trying to find a way that would work with both compilers, so we don't have to break the compatibility.

It's actually not that hard for us to go through the files and replace things, but we do care about people still using libsass for whatever reason.. At this point it would be actually easier to just drop support for libsass and go with that, but that's not the way we would like to solve this problem..

[shehi]

@alpadev , many of us here are open-source devs already. We are calm, and we already know the topics you are advocating

My argument was: Bootstrap 5 was just released, with a new major version. The fact that a deprecated tech was still actively supported in this new version "without considering" the possibility that others might move on (like Dart Sass did, which is the future of Sass). Now clearly as far as I can see, that "backfired". That's why I suggested to fix that "mistake" as fast as possible, dropping a clarification/reasoning blogpost behind this decision to your users. Otherwise, we will have to live with it until Bootstrap 6. Of course it might be possible to add wrappers around compilers etc etc, but then you might put your enterprise users in disadvantage as well, potentially lengthening build times because of these new unnecessary overheads.

Otherwise, as I already mentioned, we understand your points. Good luck with decision-making, I really hope eventually it works out for most of us, the users.

[ErbolLab]

yarn add sass@1.32.*

This fixed the problem for me.

[maartenelgar]

yarn add sass@1.32.*

This fixed the problem for me.

Massive help thanks! Fixed all the warnigngs

[forgetallpast]

It's the one fixed all this warnings... Cost about half to one hour .... https://github.com/forgetallpast/bootstrap-scss-v5.0-no-warning

So, just copy this one to your bootstrap scss folder, no warning~~~

[LoranKloeze]

If you use Rails, add this to your package.json as a temporary solution:

  "resolutions": {
    "@rails/webpacker/**/sass": "1.32.12"
  }

Don't forget to run yarn install afterwards.

Did I already mention this is a temporary solution? Because downgrading is bad and this is downgrading so it's bad.

[mdo]

I've been slow to respond because of some travel lately, so apologies. In talking with the maintainer team over Slack off and on the last few days, we still don't have a single bulletproof solution. Here's a summary from my perspective on past decisions and current status.

Our default and preferred Sass compiler is Dart Sass. See our docs for a mention of this. Libsass is tested via CI to ensure compatibility, but we don't really need it IMO. We test for it to ensure compatibility, but I think we can call that covered with v4.x being maintained for a little while longer. If we completely drop Libsass (we technically already did, we just test for it as a nicety here), we can use the math.div() function. I'm in favor of this.

Alternatively, and still incomplete and somewhat complicated, I've prepped a branch to change most division to multiplication where I can. For example, $variable / 2 is now $variable * .5. However, the incomplete part is our grid columns mixin, RFS, and some color functions use much more complicated math. Not as simple as the rest. I don't know how best to tackle that unless we implement some clever custom divide() function (which @alpadev has spiked out elsewhere). This approach doesn't feel right IMO.

Putting it all together, I think we do the following:

1. Convert what we can to multiplication for clarity and brevity.
2. Use the math.div() function for things that cannot be as easily converted and for RFS (which is vendor-ed into our _scss folder).
3. If needed, update our documentation to clarify Dart Sass.

Let me know your thoughts, folks. I'd love to get this fixed and then ship v5.0.2 so we can move onto v5.1.0.

[cverond]

Alternatively, and still incomplete and somewhat complicated, I've prepped a branch to change most division to multiplication where I can. For example, $variable / 2 is now $variable * .5. However, the incomplete part is our grid columns mixin, RFS, and some color functions use much more complicated math. Not as simple as the rest. I don't know how best to tackle that unless we implement some clever custom divide() function (which @alpadev has spiked out elsewhere). This approach doesn't feel right IMO.

it shouldn't have been / 255 equivalent to * 0.004 (choose the preferred rounding)?

[ffoodd]

Shouldn't dropping Libsass support be considered as a breaking change? Releasing this in a patch version doesn't feel right.

Other consideration: starting to use Dart Sass newest features probably needs an overall refactor. My concern is: do we simply use math.div() for support, or do we fully embrace Dart Sass syntax and features?

[mdo]

Shouldn't dropping Libsass support be considered as a breaking change? Releasing this in a patch version doesn't feel right.

We don't explicitly support it, and we talk about it like we dropped it. Another example: https://blog.getbootstrap.com/2020/11/11/bootstrap-5-alpha-3/.

Other consideration: starting to use Dart Sass newest features probably needs an overall refactor. My concern is: do we simply use math.div() for support, or do we fully embrace Dart Sass syntax and features?

I think we iterate our way forward. I'm not opposed to Sass modules, but that stuff is wildly verbose IMO and we don't need to address a full migration just yet.

[mistic100]

I hope you will be able to publish a 4.7.0 compatible with Dart Sass. I guess I am not alone working with many v4 plugins not yet compatible with v5 but have our build chain upgraded do newer versions of sass (in my case ng-packagr for an Angular librairy)

[dgpokl]

Shouldn't dropping Libsass support be considered as a breaking change? Releasing this in a patch version doesn't feel right.

[EDIT: This is merely an opinion and I'm "just some guy" - I'm not speaking for ANYONE here least of all the maintainers]

In my perspective, users who really want to stick with libsass can pin bootstrap at the previous (the present) version. In the long term, sass making this choice to break API compatibility does mean that if anyone's super serious about staying on libsass, they will very, very soon have to weigh whether they love libsass enough to perhaps pay someone to maintain a hypothetical "bootstrap-libsass" fork starting right about now, or if they are also willing to just stop getting updates to bootstrap. With bootstrap being pretty mature that's a pretty fair and not too burdensome ask.

I'm not really knowledgeable enough about libsass to judge whether that's a reasonable decision nowadays compared to updating your build process to use dart-sass and moving on, all I know is that switching to dart-sass was a huge speedup so 🤷‍♂️

[mistic100]

polyfill implemented by angular components https://github.com/angular/components/commit/a4043f41f539ed910c80c780e1815f5625282b94#diff-4b0d3692fae1e26970f5365a78db4ff81acb362f79ef12252081df8b285d38e8

(i don't know if this prevents the warning to show)

[alpadev]

@mistic100 That's not a polyfill (at least none that works with libsass).. They make use of SASS modules in there. Libsass wouldn't compile with that code.

[mdo]

Slightly altered approach has arrived in #34245.

[VArsenyan]

Is there any fix? or not yet?

[corny]

Is anyone working on a fix for the v4 branch?

[XhmikosR]

@mdo we actually need to fix rfs upstream in the 9.x branch too and update then update it here.

[wszydlak]

I've found near perfect solution to work out with supporting both libsass and dart-sass.

@function private-div($a, $b) {
    @if not variable-exists("__legacy-libsass") and call(get-function("function-exists"), "div", "math") {
        @return call(get-function($name: "div", $module: "math"), $a, $b);
    } @else {
        @return $a / $b;
    }
}

This only need's in libsass usage adding variable before any imports $__legacy-libsass: true;, eg.

$__legacy-libsass: true;

@import "~bootstrap/scss/_variables.scss"; // this needs to use private-div function

I think that for now this is the best solution to have compatibility both with libsass and dart-sass without any warnings.

[alpadev]

@wszydlak if you're ok with the output of @use to the CSS when using libsass you could also do it like this, so there is no need to add some variable (your code also requires @use to work, right?):

@use 'sass:math' as *;

@function private-div($a, $b) {
    @if function-exists('div') {
        @return div($a, $b);
    } @else {
        @return $a / $b;
    }
}

[cesarkohl-voxie]

I hope 5.0.3 is released soon.

[castellinosoftware]

Is the deprecation expected to be resolved in branch 4 as well? I know this means switching from libsass to dart, but there are projects that directly import bootstrap4 scss sources

[slavede]

I've opened PR for v4-dev here https://github.com/twbs/bootstrap/pull/34386

[Jobin-S]

how can i solve this issue?

[brandlumin]

yarn add sass@1.32.*

This fixed the problem for me.

I don't know if I did correct but ... I am on Node 12, tried it after adding sass@1.32.12 and the gulp reported no warning from sass. I know it is a bad thing to downgrade but it was highly needed at present.

[yktoo]

It would really be nice if you backported the fix to the actual mainline 4.x version, as this is the only one used in production at the moment.

[mistic100]

@yktoo it was already done https://github.com/twbs/bootstrap/pull/34571
Now we just wait for 4.6.1 and/or 4.7.0 release

[KKrisu]

Do you know maybe, when the release is going to happen @mistic100 ?

[mistic100]

I am not working for Bootstrap 😉

Sent from MailDroid

-----Original Message----- From: Kris Kesy @.> To: twbs/bootstrap @.> Cc: Damien Sorel @.>, Mention @.> Sent: mer., 06 oct. 2021 10:16 Subject: Re: [twbs/bootstrap] Sass deprecation warning: Using / for division is deprecated (#34051)

Do you know maybe, when the release is going to happen @mistic100 ?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/twbs/bootstrap/issues/34051#issuecomment-935721422