Replies: 3 comments
-
|
Because we add the style tag when the module is run, Snowpack's style tags should be following/respecting whatever import order the browser uses natively. Your use case is interesting because it's not loading through the web browser. Does this actually work in the wild, on a deployed site? Can use use a web URL or relative URL instead of a direct path to the file on disk ? |
Beta Was this translation helpful? Give feedback.
-
|
They do load once the module is run, the problem is the order they're injected doesn't respect any CSS dependency graph that might exist so you can have files stomping each other as they're injected. If the entrypoint imports On my last project we used @modular-css/rollup-rewriter to after-the-build update any dynamic |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about it, a full dependency system may not be needed? It might be enough to be able to specify that the CSS being output is comprised of multiple files, list those files, and then any CSS proxy modules would check to see which files are already loaded on the page and not re-inject those. It'd be a very lightweight form of tracking that would at least solve the CSS Modules/modular-css issue we're discussing here I think. |
Beta Was this translation helpful? Give feedback.
-
I know that a question similar to this was asked previously (#1265), but feel like this is different enough to warrant a new discussion. Please let me know if you'd prefer I ask this in that thread.
Snowpack currently supports CSS Modules, but does no CSS dependency tracking. All CSS modules are wrapped up in proxy JS modules that are loaded via the browser's ESM semantics and immediately dump their CSS payload into a
<style>tag at the end of the<head>. This leads to situations where styles are stomped due to CSS Modules expecting that cross-file compositions will be written out in dependency order so that later declarations can overwrite earlier ones.I know this is a subtle thing, so I've created a gist which will repro this issue:
https://gist.github.com/tivac/52dfc720dd74eda76f03c8c6b579737d
I ran into this issue while working on a snowpack plugin for modular-css, my implementation of the CSS Modules spec. Unfortunately I can't ship it because snowpack doesn't seem to have a concept of CSS dependencies and injecting the
<style>attributes in any specific order.Are there any plans for any functionality like this? Is there a reasonable workaround for folks using either the built in CSS Modules support or other custom styling approaches that depend on CSS being in a specific order?
Beta Was this translation helpful? Give feedback.
All reactions