Extending a modules whilst using variables from the module

[abdullahseba]

I'm writing a SASS based CSS library that is designed to be extended in a way similar to Bootstrap. The library was originally designed to be used with the @import system, and as the docs and blog post mention that this will eventually be deprecated so I have been migrating to the modules system. The main issue I have stumbled across is that there appears to be no way to use a variable from the same module within the with() configuration. For example (I'm using Bootstrap as an example here):

@use 'bootstrap' with (
    $primary: $purple
);

Previously, you could simply do something like:

@import 'bootstrap\vairables';
@import 'overrides'; //contains $primary: $purple
@import 'bootstrap\vairables';

I have tried the following but it does not work:

@use 'bootstrap' with (
    $primary: bootstrap.$purple
);

Error: There is no module with the namespace "bootstrap".

Is there any way to solve this? Maybe some sort of private _self namespace only available within with()? And is there a way to split the 'with' configuration across multiple files to stop it being potentially very long? I prefer to have a dedicated file for module-specific variables which import the 'shared' variables file. The modules system make this particular approach very cumbersome. Maybe I'm doing this all wrong, but I'm facing many issues as a result of this which completely break the library! I know @import is still supported but I don't really want to create a new library based on a system that will eventually be deprecated.

[cpoftea]

The first, Bootstrap sass built with imports and dev team is not going to switch to sass modules in the close future twbs/bootstrap#30025. So, you can't use sass modules the old way with Bootstrap (believe me, I tried). You should think of Bootstrap as only-once-configured vendor. If you want to use some of their mixins or functions, you have to write wrappers with your own variables.

[abdullahseba]

I only used BS as an example as it is used (perhaps confusingly) in the docs. I did wonder if this was the reason for the BS team choosing not to use the module system but according to twbs/bootstrap#29853 (comment), it is due to the discrepancies between the SASS compilers. The point is, what alternative is there if @import is going in the future? The nice thing with SASS before was that it wasn't just for building your CSS, but it could be extended without touching the original code. The module system seems to fall short on that. I understand the readability issues with imports but I personally never saw it as a major issue as CSS behaves like that anyway. I'm just hoping that there is a clean way of achieving this under the module system even if it involves a major rewrite. If there isn't, then I think SASS will not be as useful as it used to be for sharing themes and UI libraries that are modular and extendable. I originally thought that the module system would be perfect for themes and libraries but having used it, it feels too much like JS modules that are highly restrictive.

[jathak]

This isn't allowed because it violates the import-once semantics of the module system. Since each module is only loaded once, it's not possible to use a module's own variables when configuring it (since the configuration needs to exist before the module is loaded).

[abdullahseba]

@jathak I realise that, but are you saying there are no alternatives and that this isn't an issue? Surely SASS can load all the variables of the module being configured into a "special" namespace so that they can be used within the configuration? I'm not saying that is how it has to be done but it seems obvious to me that this is a common situation when using any SASS library. I can do this with Bootstrap now under the import system but when and if they transition, how will this be possible?