Limitations of @use for chunking

To keep this short. I essentially have a number of files that import a number of modules that have overlap.

External modules: theme, layout, button, menu, `dialog.

• /splash/firstpaint.scss imports theme

• /splash/index.scss imports splash/firstpaint.scss and button.

• /firstpaint.scss imports splash/firstpaint.scss and layout

• /styles.scss imports a set of files that eventually import /splash/index.scss, layout, button, dialog, menu modules

Client-side, there’s only firstpaint.scss and styles.scss.

firstpaint.scss imports via @use the bare minimum of UI components to achieve a first paint. styles.scss has a differed loading strategy. The goal is to get styles.scss to NOT import rules that overlap with firstpaint.scss.

I can manually achieve what I want by commenting out external modules that overlap, but that heavily negates the benefit of modules loading if I need to manually track what’s loaded and where. It also gets cumbersome when working with a large project (This example is a simplification of one with 72 @use operations).

I figured, perhaps I could a blank reference instead, so I don’t have to comment out all the overlapping modules. So in styles.scss, before processing the file tree, I can manually add:

@use "_blank.scss" as theme;
@use "_blank.scss" as layout;

In theory, it will be blank for styles.scss since it’ll be already included with firstpaint.scss. But SCSS seems to handhold a bit aggressively here and throw: SassError: There's already a module with namespace "layout". Yes, I know the module exists, and that’s the intended effect. Perhaps, we can relax this error to a warning either permanently or via an argument. Maybe some syntax similar to !default where if the module is already imported, then it can be optionally overridden.

Another option would be a rule that force unloads a module: (eg: @exclude, @disuse @unload, or @unuse). Basically we tell sass NOT to include the imports.

The last is obviously create some integrated chunking system. Then I can have three files, firstpaint.scss, styles.scss and chunk_firstpaint_styles.scss. I would think that would require the most amount of work, since it goes outside of working with one file at a time.

---

I apologize this already exists in sass, or maybe there’s something in webpack that will do this for me.

[clshortfuse]

@nex3 I’m aware of that and I’ve read that prior to comment. I know my initial comment is long, but I suggest you try to understand the point I’m making

I’m not asking for SCSS to do the code-splitting. I’m saying to facilitate code-splitting. The problem is that is users of SCSS have to manually compile a list of modules are imported then @use become just as limited as @import. The point of @use is that you don’t have to worry about a subnode (in the import tree) reusing an @import. But in the context of code-splitting, it doesn’t allow it.

We believe that this module system can work in concert with external code-splitting systems.

That’s what I’m suggesting. And as I stated, LESS has a @import (reference) syntax. That’s not code splitting. That just facilitates code-splitting. It’s not the same thing.

[clshortfuse]

Another thought. Perhaps if there was a line in styles.scss that says it expects all the modules inside firstpaint.scss to included and won’t include it itself.

Something like @expects './firstpaint.scss';.