Replies: 3 comments 12 replies
-
|
This sounds interesting, I'm not sure I understand the hash thing? Are those in the module or arbitrary? |
Beta Was this translation helpful? Give feedback.
-
|
When using CSS Modules, it gives you back unique CSS class names on generation (e.g. Since in JS all you need are those class names as strings, and not the CSS itself, it’d be a big performance win to only embed those into JS. |
Beta Was this translation helpful? Give feedback.
-
|
I like this. It also seems to relate to my proposal, here: #1327 In short: one of the tricky things about CSS is that we don't have control over the baseURI when we convert a CSS file into a JS file, like we do for Over all though, I think the "get rid of .css.proxy.js files for production builds" idea is sound, and may even solve the problem of relative-URLS-converted-to-absolute-URLs not being handled correctly by downstream bundlers (see the discussion for details). |
Beta Was this translation helpful? Give feedback.
-
|
I’m also interested in this, but have to recognize that — at least for the CSS side of this — it looks a lot like bundling. Considering that Snowpack has put a lot of emphasis on “bundle-free”, might this be an opt-in bundler? |
Beta Was this translation helpful? Give feedback.
-
That sounds very much like what I would be looking for (IIRC, @ParamagicDev is working on an integration with Rails, which is what I would be trying to do). In development, that should be perfect for determining the set of preloads. In a static build, I would expect that manifest to also have been transformed (e.g. if files were bundled, I don't need the transitive dependencies, I just need to know what the bundle file is; if assets were fingerprinted, I'd expect to see the fingerprinted asset paths, if a Javascript file is no longer adding the CSS implicitly, I'd expect the file to list the built CSS file as an 'implicit' dependency; etc.).
I think there's a lot of complexity hiding behind the word "needed" in that sentence — e.g. if my Javascript has several entrypoints that share a subset of the code, then a single "build partial" would load some amount of unnecessary code, and a "per-entrypoint" partial would load some amount of redundant code (if I loaded multiple entrypoints). |
Beta Was this translation helpful? Give feedback.
-
|
Wow I missed a lot here. Long story short my plugin removes those pesky All assets imported by rollup are fingerprinted / hashed. I have an example directory you can try out in the repo as well. |
Beta Was this translation helpful? Give feedback.
-
|
thank so much @ParamagicDev for this!! I started using your plugin yesterday and the behaviour you describe works perfect for me. There is no trace of css in my JS files and I can use |
Beta Was this translation helpful? Give feedback.
-
|
@cortopy That's amazing! Glad to hear it worked for you! |
Beta Was this translation helpful? Give feedback.
-
|
Woo! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
When you add a statement like
import 'styles.css'in your JavaScript, Snowpack transforms that into a.css.proxy.jsfile so you can load the CSS. Default behavior is we just inject a<style>tag into head with that CSS. While that’s a common (and efficient) pattern for local dev servers, it’s not great in production.Proposal
I’d like to propose getting rid of
.css.proxy.jsfiles in production, (with 1 exception) and instead just load the CSS directly in the HTML with a<link />tag. This is how that’d roughly shake out:Scenarios
Simple CSS
Basic CSS is simple to handle.
Static imports
- import 'styles.css';Simple: static imports just disappear. Of course, we’ll use these to build the final compiled CSS, but the reasoning is if it’s statically-imported, it should all be served as one CSS request, not multiple.
Default imports
The assumption here is that if a default import occurs, its purpose is to get the URL. Inline it, rather than fire off another request (again, keeping in mind that the actual CSS will be rolled up into one central CSS file loaded in the HTML).
CSS Modules
or
This is where I’d like to propose something a little controversial, just to gauge interest. In this scenario, we inline the values, just as we would a URL. This saves a request, while fulfilling the same purpose. All the JS needs is the strings of the compiled class names.
Dynamically-imported CSS
What about
import('styles.css')? Well we want to preserve the async nature of that, so perhaps those should stay as.css.proxy.jsfiles? 🤔 I can’t think of a better solution for that.Mechanism
So assuming all of that is workable (and please give feedback if it’s not), where should we implement this?
My first assumption would be to use
@snowpack/plugin-optimizeas a pure build concern. Why? Because that way this could automatically handle all CSS preprocessors and frameworks because by the time that runs it’ll only be dealing with native CSS & JS. It’d offer the widest support with the least impact.Implementation would be something like:
<html> <head> + <link rel="stylesheet" href="/compiled.styles.css" /> </head>Of course, the
compiled.styles.cssfilename can be configured. Also, it only should contain styles imported, not every loose.cssfile in your project (this would only be CSS statically imported from JS withimport …, and nothing else)Alternatives
Other alternatives would be possibly core Snowpack itself, however, that would complicate the core repo and possibly not work Day 1 with all the different setups/frameworks. But open to arguments there if this would be useful outside of
@snowpack/plugin-optimize(though it might be a fair assumption that if using the webpack plugin, etc., webpack doesn’t want this extra transformation).Questions
is-visiblemight get accidentally stripped out. Chris Coyier had a good writeup on how deceptively-tricky this can be.Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions