@at-root breaks with @use above it

[kerryj89]

I don't know if this is a bug or some intentional language design gotcha I'm not aware of.

Anyway, I migrated our styles to use math.div(). That worked great, or so I thought...

Apparently @at-root breaks when used with @use above it:

//styles.scss

.namespace {
    @import "foobar";
}

//_foobar.scss

@use "sass:math";

@at-root {
    .foo {
        width: math.div(6px, 2);
    }
}

.bar {
    width: math.div(6px, 2);
}

If transpiles into the following:

// styles.css

.namespace .foo {
    width: 3px;
}
.namespace .bar {
    width: 3px;
}

I expected the following:

// styles.css

.foo {
    width: 3px;
}

.namespace .bar {
    width: 3px;
}

I tried the following:

• Using @include meta.load-css("foobar") instead of @import
• Wrapping @at-root within a mixin and calling it immediately
• Move @use below @at-root (errors out as expected, but thought I'd try)

--

If I remove @use and just use the division symbol like previously it outputs as expected.

[jathak]

@kerryj89: Wanted to give you an update on this. This behavior is definitely a bug, but it's also very difficult to fix, so we've been having trouble getting it to work.

In the meantime, I wanted to offer a workaround that will allow you to use math.div without breaking @at-root:

// styles.scss
.namespace {
    @import "foobar";
}

//_foobar.scss
@import "division";

@at-root {
    .foo {
        width: math-div(6px, 2);
    }
}

.bar {
    width: math-div(6px, 2);
}

// _division.scss
@forward "sass:math" as math-* show math-div;

[kerryj89]

Nifty! Thank you so much for showing me a workaround.

[kerryj89]

@jathak Working as intended. Thanks for all you do!

[jathak]

Reopening this since we never actually fixed it in the general case. We've fixed this for @use rules of built-in modules, but were unable to find a solution for other @use rules.

Marking this as "help wanted" in case someone else can find a solution, but it's not something we currently plan to work on more ourselves, since this is behavior that's not supported when fully using the new module system, so fixing such a complex bug that only manifests in code that's already partially migrated isn't something that we have the bandwidth for.