Can't @use or @forward a file

[arch-daemone]

Describe the bug
Despite using the latest version of sass, which implements the new module system, scss-bundle won't let me use @use or @forward to import a file. Having just refactored a massive monorepo (136 files touched) to use the new system, this was not a nice thing to see in our Jenkins console.

To Reproduce
Steps to reproduce the behavior:

1. Create a new directory, with two files, index.scss and _child.scss
2. In index.scss write the line @use 'child';
3. In _child.scss write some basic CSS, like body { height: 100%; }
4. Run scss-bundle with index.scss as the entryFile
5. Terminal prints an error that it "Can't find stylesheet to import", pointing to the line with the @use.
6. Observe that if you change to using @import, everything works as expected.

Expected behavior
I would expect files imported with @use or @forward to be found and bundled correctly.

Package version: v3.1.1
Node version: v12.14.1
OS: Windows (but also Bash on the Jenkins box)

[arch-daemone]

Ah. I started looking into this myself this morning, thinking I could maybe submit a PR, and discovered that it would actually be quite a lot of work! Since you can't just pass off to Sass itself to do the hard work of bundling, scss-bundle would have to fully implement all the new behaviour of the module system. Off the top of my head:

• "used" modules' variables/functions/mixins need to be namespaced, both in the declaration and in the usage:
  • a.$variable --> $-a--variable or something (made private because used variables are not re-exposed);
  • Significantly, this needs to account for both @use 'foo' and @use 'foo' as bar syntax when it comes to finding usages, and ideally should be done in such a way that the used file is only included in the bundle once, and its variables referenced repeatedly wherever the file is re-used;
  • In fact, the namespaces we assign should be something generated and highly likely guaranteed to be unique, so they can effectively be reused globally within the bundle file;
• forwarded variables need to be made a part of the same namespace as those of the used file that forwards them;
  • Also, uses of @forward 'foo' as foo-* syntax need to add the inner namespace to the names of variables, as well as the outer namespace of the module doing the forwarding;
• Private variables (marked by identifiers that start with - or _) need to essentially be erased from the bundle: their values calculated and uses of them replaced with the calculated values - there's no other way to ensure that they aren't exposed;
• Uses of @use 'foo' with () need to correctly assign to the named variables the values that are being passed in;
  • But only the first time the module is used. All subsequent imports should use the values provided the first time, and scss-bundle should throw an error if more than one module tries to configure the same module with with;
• Of course, the major one: with all of these approximations of the module behaviour, what's actually exposed to consumers of the bundle still needs to be what would be expected if the whole thing were still separate modules,

I'm sure there are other things to add (especially in the area of errors to throw) but already that's got it looking pretty complex. I'd still like to take a pop at it, but if one of the more regular contributors can see a solution and beats me to it, I'll be happy with that too!

[DovydasNavickas]

@DaemonExMachina, glad you took a look into this. We departed from using scss-bundle and even scss itself into using CSS-in-JS provided by Emotion, so this module system is new to us.

Looking at your last post (it is pretty exhaustive, thanks for that!) it seems that the module system is quite similar to JavaScript / TypeScript ones. Just not sure what does @use 'foo' with () would do yet 😄

Your observation about scss-bundle needing to implement a lot of things is correct too. Right now, scss-bundle only keeps a registry of files, dedupes them, and prints everything into a respective. Supporting module system though needs reading the SCSS AST and most probably manipulating it, which isn't foreign to us as we've worked with various tools using AST. But at the same time, as we're not using SASS for quite some time, it would be a rather large investment into researching and implementing everything.

If you want to tackle this, please do. We can support you, but having neither financial benefit nor usage in our organization, it's unlikely we are going to implement this very soon.

[arch-daemone]

Ah yeah, if you haven't been reading up on the new modules some of what I wrote would be absolute gobbledygook!

I totally get why this wouldn't be a priority in that case. To be perfectly honest, we're working towards not needing scss-bundle too, but I'm not sure how long that's going to take. There are a few steps to get there, and we may not even go all the way there. Basically, if we can get away with using CSS custom properties (variables) for theming, then we don't need to build a SCSS bundle to export for clients to manipulate to build their own themes. They can just write some overrides for the (many many) CSS variables and attach them to :root.

I'm interested in the challenge of making this change, though. Playing with parsers, reading ASTs... yeah, that's something I've always wanted to explore but never had reason to. Every build tool and linting rule I've needed so far has already been built by someone.

Just for fun, then: the with syntax allows you to configure a module the first time you load it. You declare some variables with the !default flag in the consumed module, and the first module that loads it then passes it values for those variables.

// _child.scss
$var1: blue !default;
$var2: null !default;

body {
  color: $var1;
}

// index.scss
@use 'child' with (
  $var1: red,
  $var2: green
);

It's a concept that already existed: a browse through the Bootstrap stylesheets, for instance, would show lots of those !default values. But you would just declare the overrides globally before importing, and that would be that. Here it's much more explicit that these are being passed in, and there's no fear of name collisions or other accidental interference.

[marksmccann]

Do we anticipate an progress being made on this feature enhancement? If so, is there anything I can do to help? If not, do you know of any good workarounds? In my head, this enhancement would be perfect for my use case, but maybe there is an alternative I am not considering?

[DenysVuika]

This is a blocker for us as well, any plans to resolve this issue?

[nickstaroba]

@DenysVuika One workaround I found was to create a "set up" file that has only your @use statements and then bundle that file first. I'm using gulp:

src("./src/_setup.scss").pipe(src("./src/_other-file.scss")).pipe(concat("index.scss")).pipe(dest("./dist"))

It's not a the best solution since you can't have the @use statement at the top of the other individual scss files, but it's working well enough.

[sergiubologa]

Any updates on this? Is there a workaround?

[sonikasharma1403]

Any update on this?

[sumegha26]

#90 (comment)

+1

[pelord]

@ALL Do you have a solution to fix this issue?
I was refered to this issue from #108

[cgatian]

I've contributed to this repository and can say that without a major refactor/rewrite this feature will never happen.