Fix deprecation warning with Sass 1.77.7

[julien-deramond]

Warning

This PR is a draft probably tackling only a part of the problem

Warning

#474 (comment) has not been tested out as it might be another issue

Closes #474

Description

This PR is an attempt to fix #474.

Context

git checkout main
npm i sass@1.77.7
npm run test

Deprecation Warning: Sass's behavior for declarations that appear after nested
rules will be changing to match the behavior specified by CSS in an upcoming
version. To keep the existing behavior, move the declaration above the nested
rule. To opt into the new behavior, wrap the declaration in `& {}`.

More info: https://sass-lang.com/d/mixed-decls

    ╷
153 │ ┌     .enable-rfs &,
154 │ │     &.enable-rfs {
155 │ │       @content;
156 │ │     }
    │ └─── nested rule
... │
299 │           #{$property}: if($rfs-mode == max-media-query, $fluid-val, $val);
    │           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ declaration
    ╵
    scss.scss 299:9            @content
    scss.scss 167:7            -rfs-media-query-rule()
    scss.scss 298:7            rfs()
    test/sass/_main.scss 38:5  @import
    test/sass/test-4.scss 2:9  root stylesheet

Warning: 18 repetitive deprecation warnings omitted.

The issue comes from our internal mixins _rfs-rule and _rfs-media-query-rule that can both render @content; without any selector; that causes for instance this kind of rules:

@content;

.enable-rfs &,
&.enable-rfs {
   @content;
}

@content;

Since there are supposed to be internal mixins, I supposed that I could modify them without any problems for users, and chose to only extract the problematic rule from _rfs-media-query-rule, and use it before calling _rfs-rule:

@if $rfs-class == enable {
    @if $rfs-mode == min-media-query {
      @content;
    }
}

Maybe there's a smarter way of doing it, but I'm not that familiar with this repo.

[paulthewalton]

I'd love to help push this forward, but at this point I'm running into the issue of LibSass and Dart Sass having diverged quite significantly (mixed-decls, CSS if() #492 , @use instead of @import #363 ), and bringing this repo inline with Dart Sass is breaking the LibSass tests. Now that LibSass is deprecated and fully end-of-life, should support for it in this repo also be dropped, or moved into a new entrypoint (something like libsass.sass in the root) to maintain support as it is for those users?

[julien-deramond]

Even though I'm part of the Bootstrap core team, I've never really participated in maintaining this repo, apart from this draft PR, so I don't want to speak for the RFS maintainers.

What I can say, though, is that the situation on the Bootstrap side (the main repo) is clearer now than it was in 2024, when I opened this PR:

• Bootstrap v5 will remain pinned to Sass 1.78.0, while retaining compatibility with Node Sass. Moving beyond that would require a broader refactoring.
• That refactoring happened in v6, where we dropped Node Sass support altogether.

On top of that, Bootstrap v6 no longer uses RFS. So, perhaps RFS could take a similar path and drop LibSass/Node Sass support in a new major version, allowing the codebase to move forward with modern Dart Sass without having to preserve compatibility with an EOL implementation.

That's just one possible direction, of course, but it might be worth considering.

Note: I'll probably close this draft PR

[paulthewalton]

Note: I'll probably close this draft PR

I've created a new draft PR ( #499 ) with my changes regarding a couple of syntax changes, and moving LibSass support to a new entrypoint