Global vars with @use

Started to use the new modules with @use which are awesome, but not sure if I’m missing something, but I don’t seem to be able to define global vars anymore. Whereas with @import, I could…

// vars.scss
$color: red;

// body.scss
body { background-color: $color; }

// main.scss
@import 'vars';
@import 'body';

but fails with modules…

// vars.scss
$color: red;

// body.scss
body { background-color: $color; }

// main.scss
@use 'vars';
@use 'body';

Now I know could add a @use to the top of body.css, but that means that I would have to do that in every single file that uses the variable.

Apologies if I have overlooked something, but any help would be appreciated here. thank you.

[meduzen]

Hi,

I spent the last 6 hours reading the adopted spec, some issues, the Miriam’s article on CSS Tricks and I also tried the migration module in a project.

First, thanks to the SASS team for bringing modules, that’s awesome.

Second: sorry, this message is a very long.

Now, let’s go (sorry, really).

Thinking about reconsidering @import purpose is naturally okay because it’s a CSS feature (and so should some colors functions like hsl :p). However solving this minor issue the way the SASS module spec does it is, I think, not ideal to strengthen the whole module system adoption, hence the existence of this issue and #2753.

@nex3: quoting your message posted yesterday, because it’s the good start for what I want to communicate:

I understand that adding @use “config” to the beginnings of all your files is some amount of hassle, but ultimately it’s only one line that provides many benefits. Many other programming languages work very well with similar requirements.

• There are other programming languages that still allow you to import your stuff globally despite of their modular and namespaced capabilities (at least JS and PHP).
• CSS is a programming language with a completely different paradigm, mainly because of the cascade, and what is especially awesome with SASS @import is that it perfectly brings the cascade concept for SASS members: when I @import a SCSS file (a partial or a package), the members (mixins, functions and variables) are available in all the following imported stuff. Same paradigm as CSS, same expectations, and leads to the most clear and readable way of using SCSS members.

I know that the module spec provide a way (as mentioned by @mirisuzanne) to kind of importing several stuff in once by combining @forward and @use, but it remains very cumbersome having to repeat the @use at-rule everywhere an import has to be done, especially in large projects: my four last ones have between 90 and 210 partials, and they are not big ones.

So, I don’t agree that “ultimately it’s only one line”. It’s way more, and in an ongoing development, I’ll have to check a ton of times what I should import where, in addition of having to check here and there what stuff is/does what (because, sometimes, you just don’t remember).

Also, another (smaller) side effect of removing the @import awesomeness is that it becomes complicated to have very short members names as you can’t have a public mixin starting by an hyphen or an underscore. I have a package in development that brings short mixins like --w (to generate custom media queries): yes it’s an edge case, and I would have to think about the whole naming used in my Double Dash package, making it potentially less awesome (self-certified awesomeness ©) if users can’t use it globally in their projects.

The two-years awesomeness period

The thing I don’t really get is: why introducing SASS modules (which are absolutely awesome and needed) should lead to the loss of completely global members. We could have both, like in other programming languages, because sometimes you want namespaced stuff, sometimes you want global stuff.

As there’s a two-years period foreseen before @import is doomed, I’d say: if it can technically work during two years, why removing it? I would fully understand a rename of this at-rule, so it doesn’t get mixed up with the CSS @import.

But we’re literally entering a two-years golden-era that’ll have both modules and global import. Why should it stop?

What is readable and what isn’t

As long as any variables are globally available without any explicit opt-in, all the negative effects that the goals of the module system sought to avoid would still be present. Users would still need to assume that short variable names were unsafe, readers and tools would still have no way of knowing where a given variable came from […].

I don’t think one of the goals of a tool like SASS should be to decide what is readable or understandable for the user. I could argue that having a ton of @use in various files will exactly lead to the same issue: the user won’t more clearly picture which things must be imported from where nor what a specific member is or means.

The readability, understanding and onboarding in a SASS project rely on how code authors organize how write their names, structures and other stuff: they can be organized or messy with or without SASS modules and with or without global members. For example, I never encountered the several import of the same file mentioned in the low level goals, aside from when a workflow tool (using a task runner) is screwed.

At the end, it’s best to let people organize their code the way they want, because there are various teams, people backgrounds and projects configurations leading to various perceptions of what is readable or not, and because SASS is a wide tool, not a closed methodology: BEM is a methodology and you can still organize yourself the way you want, but SASS is a tool and you can embrace only certain features if you don’t need everything.

My perception is that you fear the module system won’t be widely adopted, so you’re pushing it a bit too much (I maybe wrong, it’s my perception), and I think that firmly stating now that @import must be deprecated at some point is too early. I think it would be better to wait for people to discover the module system (we still need implementations to be done), use it, and collect feedbacks: maybe everybody will be fine and the spec won’t move, maybe it’ll be an opportunity to reconsider what to do with @import (rename it 👼).

To sum up (finally ¯\_(ツ)_/¯)

I really think the removal of a global scope will slow down the SASS modules adoption:

• some people will try it;
• some people will stay on an earlier SASS version, because the clarity brought by the @import cascade is a more powerful tool than SASS module;
• others will look at other ways to write CSS, for example using Post CSS: I use both SASS and PostCSS in every project and they works together very well, but at some point I’d may be tempted to check if my CSS workflow is fully transferable to PostCSS (or I’ll stick to SASS pre-modules).

Hey, again, there is a tremendous work that was done here! I’m really concerned about this specific topic, and I understand how hard it can be to bring such a big spec in a tool like SASS, especially with a so low number of contributors.

I’m pretty sure you’ll got a number of similar feedbacks as mine in the future, maybe considering what I’ve exposed (= pause the @import removal decision until more feedbacks) will help to deal with people feedback and to strengthen the communication around modules.

[joelmoss]

ok, I understand all that, and I agree that local scope is better, but this removes one of the biggest benefits of variables - available everywhere. While locally scoped vars are great, I feel there is still a need for global vars.

I see @use as a “local module” 👍

By removing @import, we no longer have any ability to define global vars without having to add a @use in every file that uses said vars.

A colour palette is a great example of this, as they are usually used throughout your app, and don’t really change at all. They are not specific to any given module.