Allow using @use to import only a module's members

I wonder if it would make sense to somehow allow using @use to import only the imported module’s members (variables, mixins, functions) but not the imported module’s styles.

Here is my use case:

Supposing this is my master Sass file…

@use "components/_alert.scss";
@use "components/_button.scss";

…and this is _alert.scss…

@use "button";

.alert {
  background-color: button.$bg-color;
}

…and this is _button.scss…

$bg-color: blue;

.button {
  background-color: $bg-color;
}

… the CSS compiled from the master Sass file would be:

.button {
  background-color: blue;
}

.alert {
  background-color: blue;
}

Note that the compiled CSS for .button appears before that of .alert, despite the order of the @use statements in the master Sass file. As the documentation states, “Any styles loaded [using @use] will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded,” so this behavior is not unexpected. However, I do think it would be valuable to allow for using @use to import only members because this would give Sass authors some flexibility to use different organizational/architectural approaches.

Perhaps the syntax could be consistent with the syntax for controlling visibility with @forward, e.g.:

@use "button" hide "styles";

and

@use "button" show "mixins", "functions", $bg-color;

and

@use "button" show "variables";

where all of the above would result in styles not being imported but the $bg-color variable being imported (the strings are just example keywords that might make it easier to include/exclude members by type rather than having to do so individually).

I think it’s useful to draw a comparison with JS modules here. Conceptually, importing a Sass file using @use seems to be similar to importing a JS module that has a side effect, in this case the side effect being that the styles are outputted. Basically I think it’d be useful to be able to opt out of this side effect given that importing Sass modules has value beyond the outputting of styles (usage of locally scoped members).

[nex3]

As a general rule, it’s often a good idea to avoid having partials produce CSS output at all, in favor of them having a mixin that the entrypoint file can include:

// _button.scss
$bg-color: blue;

@mixin styles {
  .button {
    background-color: $bg-color;
  }
}

// _alert.scss
@use "button";

@mixin styles {
  .alert {
    background-color: button.$bg-color;
  }
}

@use "components/alert";
@use "components/button";

@include alert.styles;
@include button.styles;

Using your JavaScript analogy, this is what you’d do to ensure that your modules don’t have side-effects.

That said, this is something that has been requested before, so it’s not out of the realm of possibility. I’ll mark it as “under consideration” and we’ll see how many people 👍 the issue.

[nex3]

@jkjustjoshing One of Sass’s design principles is to avoid adding features targeted at using dependencies in ways their authors didn’t intend them to be used. Doing so is always going to be brittle, and it’s almost always a better long-term strategy to either contribute changes upstream, to work the way the dependency expects, or to fork it and explicitly maintain it yourself.