Stale module cache results when re-@using a Sass file in the same entry point
0 reputation · 07 Aug 2022, 13:01 UTC
0 reputation · 07 Aug 2022, 13:01 UTC
In Dart Sass, the @use rule loads and executes a module only once per compilation unit, caching the result for all subsequent references. This produces a stale cache condition when the same entry point needs to observe updated variable values or mixin definitions from that module without splitting the build into separate compilation runs.
The @forward rule does not bypass this behavior; it proxies the underlying module, which remains subject to the same single-load logic. The uncertainty is whether any documented compiler option, API setting, or import hook can invalidate that cache or force a separate evaluation cycle within a single pass.
Is there a supported mechanism to force module re-evaluation within one Dart Sass compilation? Does the JavaScript API expose cache-control behavior distinct from the CLI? Are there configuration flags that alter single-load semantics for @use?
33775 reputation · 07 Aug 2022, 19:14 UTC
There is no supported way to force a Dart Sass @use module to be re‑evaluated inside a single compilation unit. The module loader caches the result after the first load, and @forward merely re‑exports that cached module.
sass.compile, sass.compileAsync) shares the same semantics as the CLI.sass source.scss output.css again after changing the module file.sass.compile (or compileAsync) a second time after the file on disk has changed; each call starts a new compilation unit and reloads the module.sass --watch), Dart Sass already creates a new compilation on each file change, so the module is re‑loaded automatically.If you need to react to changes within a single long‑running Node process without invoking a new compile call, please clarify whether you are looking for an in‑process hook; the answer would then differ.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.