slash-no-division

What is the problem you’re trying to solve?

My current frontend tooling (w/ Dart Sass) doesn’t like division with /:

[CRA] 21 │   padding: 0 ($COL_SPACING / 2);
[CRA]    │               ^^^^^^^^^^^^^^^^
[CRA]    ╵
[CRA]     src/client/styles/modules/Foo.module.scss 21:15  root stylesheet
[CRA]
[CRA] DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0.
[CRA]
[CRA] Recommendation: math.div($COL-SPACING, 2)
[CRA]
[CRA] More info and automated migrator: https://sass-lang.com/d/slash-div

It currently logs a runtime warning, but presumably in the future it will completely break.

This will probably be caught by our tests, but it would be great if it could also be handled by styelint.

What solution would you like to see?

A new rule that shares the opinion of Dart Sass, squiggling offending uses of the /.

Is this something that stylint-scss would be interested in?

https://sass-lang.com/documentation/breaking-changes/slash-div

(originally from https://github.com/stylelint/stylelint/issues/5368)

[ahukkanen]

My main concern is the CI pipeline, when we are fixing this dart sass issue for the project. If someone introduces a new slash division after fixing it, it may go unnoticed because there is no way to catch that in the CI.

And there we cannot even grep the webpack output because there are still external dependencies that produce these warnings that are outside of the project’s control.

There’s still the possibility to write some rather complex webpack output parser that will automatically detect which warnings come from external dependencies and which come from the project itself. Or just hope for the best.

It would be much easier in such cases to rely on stylelint.

[jrr]

In addition to that, the Sass team is already providing all the necessary info and tools to migrate to the new version:

They’re providing everything except for editor squiggles 😉

For better or worse, this project seems to be the default recipient of “there ought to be a squiggle” issues like this one. Maybe a note on the Readme could map out the ecosystem a little bit, and suggest where to take issues that fall outside this project’s scope? (Is there a different project that could/should be responsible for adding VS Code squiggles for that dart-sass warning? I still don’t know.)