Compatibility with gulp-sass 4.1.1 broken with bootstrap-sass 3.4.3 and 3.4.2

[boenrobot]

At the company I work for, we have a project that uses NodeJS to compile our assets with gulp. Specifically, gulp-sass 4.1.1.

With the release of 3.4.3, we got the following error on our builds.

[08:52:22] Starting 'styles'...
{ Error: vendor/bootstrap-sass-official/assets/stylesheets/bootstrap/_variables.scss
Error: Invalid CSS after "...     floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
        on line 369 of vendor/bootstrap-sass-official/assets/stylesheets/bootstrap/_variables.scss
        from line 8 of vendor/bootstrap-sass-official/assets/stylesheets/_bootstrap.scss
        from line 43 of src/scss/main.scss
>> vbar-padding-horizontal:        floor(math.div($grid-gutter-width, 2)) !defa
   ------------------------------------------^

There is a newer gulp-sass version (5.0.0), but that one requires gulp 4 and Node 12, making that upgrade difficult (we're using gulp 3 and Node 10).

Regardless, breaking compatibility in a patch version is kind of a bad move, so I thought I'd report it. For now, we've just move back to 3.4.1 (as 3.4.2 seems was also affected, but I guess we hadn't updated since its release).

[ptjuanramos]

I believe that this should be a breaking change and not being part of 3.4.x version.

[AprilArcus]

@boenrobot, some thoughts:

1.) Gulp-sass 4.1.1 supports dart-sass. You can resolve your problem by changing the sass compiler. Remove "node-sass" from your package.json and replace it with "sass": "1.33.0 - 1.49.0". Then, in your Gulpfile.js:

var sass = require('gulp-sass');
sass.compiler = require('sass'); // was require('node-sass');

Note that dart-sass 1.33 is the first version with support for math.div, and 1.49 is the last version with support for NodeJS 10.x.

2.) Node 10 has been EOL since April 30, 2021; remaining on that version is not likely to be a viable long-term strategy for you.

@ptjuanramos You're right, but Bootstrap 4 is already its own thing, so it's not clear what the best way to signify this change would be.

[aaronbrooks-powerschool]

We are getting the same issues. Not using gulp-sass. Node version 12.17.0. Would like to know how we could get this resolved. Same error message,
sass/assets/stylesheets/bootstrap/_variables.scss: Invalid CSS after "... floor(math": expected ")", was ".div($grid-gass/assets/stylesheets/bootstrap/_variables.scss: Invalid CSS after "... floor(math": expected ")", was ".div($grid-gutt..."utt..." ) Run with --trace to see the full backtrace

[AprilArcus]

Not using gulp-sass.

You will need dart-sass (that is, the sass package on npm) version 1.33 or greater. I can help you if you'll tell me what build tools you use to compile sass. For example, do you use webpack with sass-loader? Something else?

[aaronbrooks-powerschool]

We use Grunt, and bootstrap-sass installed from bower.json. We can look into updating our project structure, although it was jarring to see these older projects fail seemingly overnight. Seeing that version 3.4.1 did not have the latest changes merged in, we were able to use that and get our builds working again.

[AprilArcus]

Grunt-sass supports dart-sass since version 3.0.0. If you want to upgrade, I suggest making sure you are on Grunt-sass 3.x, and passing dart-sass to grunt-sass's sass.options.implementation parameter.

it was jarring to see these older projects fail seemingly overnight

With respect to this, it's good practice to use a lockfile, such as package-lock.json (NPM) or yarn.lock (Yarn) to guard against unexpected updates to your dependencies.

[boenrobot]

@AprilArcus Thank you for the suggestion.

2.) Node 10 has been EOL since April 30, 2021; remaining on that version is not likely to be a viable long-term strategy for you.

I'm well aware, but it's not exactly my decision to make. Due to the huge changes between gulp 3 and gulp 4, we need to effectively fully rewrite all of our gulp scripts (of which we have like a dozen ones; mostly the same, but with minor differences between them), and that takes time that my bosses are not willing to allow right now, in favor of bug fixes and features within the applications themselves. This migration is present "on the todo list", but lower in priority.

You're right, but Bootstrap 4 is already its own thing, so it's not clear what the best way to signify this change would be.

A minor release (e.g. 3.5.0) maybe? The higher the version vector that can afford an increment, the better.

[wadtech]

Caught this by coincidence in a project so that would have been an exciting deploy. Please don't use patch releases for breaking changes.

[AprilArcus]

A minor release (e.g. 3.5.0) maybe? The higher the version vector that can afford an increment, the better.

I think that's sensible; what do you think @glebm? Is it possible to revoke 3.4.2 and 3.4.3 from npm and republish as 3.5.0?

I do want to note that a breaking change on a 3.5.0 release would also violate semver, though.

[AprilArcus]

Due to the huge changes between gulp 3 and gulp 4

As I noted upthread, you don't need to upgrade to Gulp 4. Your existing versions will meet your needs, since you have gulp-sass 4.1.1 and gulp-sass supports dart-sass since 4.0.2.

[ptjuanramos]

A minor release (e.g. 3.5.0) maybe? The higher the version vector that can afford an increment, the better.

I think that's sensible; what do you think @glebm? Is it possible to revoke 3.4.2 and 3.4.3 from npm and republish as 3.5.0?

I do want to note that a breaking change on a 3.5.0 release would also violate semver, though.

No to intrude, but the second option in my opinion makes sense 😃

[boenrobot]

As I noted upthread, you don't need to upgrade to Gulp 4. Your existing versions will meet your needs, since you have gulp-sass 4.1.1 and gulp-sass supports dart-sass since 4.0.2.

Yes, I got that part. Thank you again. We'll consider doing that.

With the gulp 3 vs gulp 4 thing, I was referring to your bigger comment about Node 10 being EOL.

SCSS is not the only thing we have in our build pipeline. If we "just" switch to Node 12, we need versions of everything in the pipeline that is compatible with Gulp 3 and Node 12. However, several of the other libs we're using in the gulp scripts don't have such versions. They have Gulp 4 compatible versions that also require Node 12+, and their gulp 3 compatible versions only support up to Node 10.

Maybe there's a way to isolate those dependencies and replace them with analogous ones that have better compatibility, similarly to how you did with dart-sass, but trying to do that ourselves also requires time we might as well spend on rewriting to Gulp 4.

[stof]

A solution to keep compatibility with libsass would be to copy the divide() function defined in Bootstrap 4 and 5 and use it instead of math.div

[AprilArcus]

A solution to keep compatibility with libsass would be to copy the divide() function defined in Bootstrap 4 and 5 and use it instead of math.div

That's an interesting idea. Links:

• New divide() function to prevent Sass deprecation warnings rfs#398
• Replace Sass division with multiplication and custom divide() function bootstrap#34571

[AprilArcus]

@stof I opened a PR incorporating your suggestion here: #1229

[mrleblanc101]

Wow, this is not very semver.
This include a breaking change, it shouldn't be in a patch release.
The dart-sass math.div change just broke many projects.
Please consider reverting the change and releasing this in a new major/minor version, not in a patch.

[mrleblanc101]

Even using lockfile, this will break project because by default npm/yarn/bower will not lock the patch version of a dependancy. So "bootstrap-sass": "^3.4.1", will update to 3.4.3 and break every project.
If the change is released under 3.5 or 4.0, then it wouldn't be an issue.

[AprilArcus]

by default npm/yarn/bower will not lock the patch version of a dependancy

@mrleblanc101 I think I understand this to mean that if you were to invoke npm install --save bootstrap-sass you would end up with a ^ pin in your package.json. package.json is not the same thing as a lockfile, which provides an additional layer of defense against potentially semver-violating breaking changes. You can learn more about lockfiles at https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json and https://classic.yarnpkg.com/lang/en/docs/yarn-lock/.

[mrleblanc101]

If I run npm upgrade it shouldn't break the project since breaking change should NEVER be published in patch version ! Also this is used in many old project which use BOWER which doesn't have a lockfile.
Please respect semver like npm.js require for publishing package...

[fahmilatib]

If the change is released under 3.5 or 4.0, then it wouldn't be an issue

^3.4.1 would still pick up 3.5 unless it's ~3.4.1

[mrleblanc101]

@fahmilatib You are right and since ^ is the default in most package manager (npm/yarn/bower) it should be release as 4.0.0

Can't believe it hasn't been fixed already as this problem is so easy to fix and avoid by RESPECTING semver. https://semver.npmjs.com/

[AprilArcus]

Please don't raise your voice. We all know how Semver works, and we're all doing our best. I'm sure you can see that with Bootstrap 4 being a separate product, the bootstrap-sass maintainers cannot cut an unrelated release of Bootstrap 3 and call it "[email protected]".

[mrleblanc101]

Yes it can. The version of this package has nothing to do with the version of bootstrap it install.
At already has diverged from the latest published version of Bootstrap 3.
And since there will be NEVER be a bootstrap-sass version of Bootstrap 4 because it's not natively compatible with Sass, it doesn't matter.
https://docs.npmjs.com/about-semantic-versioning

[AprilArcus]

I'm afraid that as I'm not a maintainer and not responsible for selecting the version number published to NPM, I can't help any further.