[Early Feedback] External Style Import Unification #28
Replies: 6 comments 19 replies
-
|
For HTML For CSS |
Beta Was this translation helpful? Give feedback.
-
|
Another possible way to bring in css is from an |
Beta Was this translation helpful? Give feedback.
-
|
There's a 4th way: ---
import xUrl './X.css?url';
---
<link rel="stylesheet" href={xUrl}> |
Beta Was this translation helpful? Give feedback.
-
|
yes! thanks, adding to the original post now |
Beta Was this translation helpful? Give feedback.
-
|
oh weird, this actually doesn't work. In the final build you get https://stackblitz.com/edit/vite-1jaulg?file=dist/assets/index.8468bb85.js You see something similarly weird in dev as well. Update: I think this is a bug with Vite and using a CSS ESM import + |
Beta Was this translation helpful? Give feedback.
-
|
I think we should consider this a bug. |
Beta Was this translation helpful? Give feedback.
-
|
agreed. OP updated! |
Beta Was this translation helpful? Give feedback.
-
|
@FredKSchott One thorn in my side right now is that I don't see any good documentation in 0.21, and some inconsistent behavior, with regards to
The main concern that I have with the proposal as given here is that form # 4, which you are proposing to eliminate, is the only form that I believe works with snowpack aliases today. As a result, eliminating that form without providing a replacement, it looks like we would complicate/uglify inclusion of library CSS? I would like to see this addressed at some point, and this RFC seems like it might be a good place to fold that in — but I defer to you wrt the scope of this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, got it. Yup, I'll add a mention that the new version of 3. would support everything that an ESM import already supports (including aliases). The idea is to pass more of this logic through Vite, so that we don't have to create a second implementation for things like aliases. fwiw 2. would also support this, but I agree that that's less useful if you're just working on an individual component. |
Beta Was this translation helpful? Give feedback.
-
|
K; in that case, I have a related question: how does any of this interact with scss? In 0.20 (which I am stuck on for unrelated reasons) import aliases don't work in |
Beta Was this translation helpful? Give feedback.
-
|
I think that that would be considered unrelated to this discussion, since that's really an issue of how Sass + Vite work together. I'm not sure what the answer is but you might have some luck googling around for phrases like "vite sass alias @use" and finding an answer in the larger Vite community. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I’ll revisit that when I can get off 0.20 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
np, thanks for the feedback! |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be good to include in the proposal a grouping of use-cases and how those would be achieved. Some examples:
|
Beta Was this translation helpful? Give feedback.
-
|
Agreed, these should be more explicitly highlighted in the rough proposal. RE 4.: I'm hoping to keep this out-of-scope, and not propose any changes to how CSS is currently supported outside of Astro components and only focus on Astro components. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming the ---
import one from './styles/one.css?url'
import two from './styles/two.css?url'
---
<link rel="stylesheet" href={one}>
<link rel="stylesheet" href={two}>
For the above reasons I think it makes more sense that, if we support this import syntax, they not be bundled. And instead treated like image assets where it is hashed and moved into |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't it be possible to add some attribute to link tags which flag them as "not to be bundled"? ---
import one from './styles/one.css?url'
import two from './styles/two.css?url'
import three from './styles/three.css?url'
---
<link rel="stylesheet" href={one}>
<link rel="stylesheet" href={two} nobundle>
<link rel="stylesheet" href={three} nobundle> |
Beta Was this translation helpful? Give feedback.
-
|
The rough proposal above is making the point that We thought that |
Beta Was this translation helpful? Give feedback.
-
|
ah gotcha! okay that would do as well, for me at least. |
Beta Was this translation helpful? Give feedback.
-
|
@FredKSchott is (3) the one that handles this use case? If so, would the external CSS be scoped? This use case is for bundling external CSS without scoping it, for clarity. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, that should definitely be clarified. I don't believe that a CSS |
Beta Was this translation helpful? Give feedback.
-
There are currently
threefour different ways to bring an external CSS file onto the page:<link href={Astro.resolve("./X.css")} /><link rel="stylesheet" href={xUrl}> // import xUrl from './X.css?url';<style>@import './X.css';</style>import './X.css'; // in Astro component frontmatterIt's difficult for us as maintainers to document, test and support so many different way to do things. Each method may support different features, or imply some different behavior. It's equally difficult for users to understand which is the "right" way to do things.
Now that #12 and #26 exist, I think we can simplify this somewhat. Here's my proposal, which is following the same logic of #12 and #26 around
<head>behavior and not adding magic (like bundling) to existing HTML elements (like<link>) without user opt-in.Rough Proposal
1. ✅
<link href="/global.css" />or<link href="https://..." />/publicor external CSS file.<link>tag in the browser.Astro.resolve()! (see other options below)public/or an external CSS URL. This will not be bundled/optimized.src/, see option 2.<head>2. ❌
<link rel="stylesheet" href={xUrl}> // import xUrl from './X.css?url';xUrl, but it still won't bundle this CSS file as you would expect. This means that the resolved URL might not actually exist in the final build, if that file had been bundled.3. ✅
<style @component>@import './X.css';</style>Note: I'm using
@componenthere in explicit reference to #12, but if that is unfamiliar then ignore it for now. This is essentially the same as our current v0.20 default scoping and bundling behavior of Astro component<style>.<style @component>element is scoped.@import './X.css';will inherit from all Vite support, including aliases and npm package@importsupport.4. ✅
import './X.css'; // in Astro component frontmatterFeedback?
Beta Was this translation helpful? Give feedback.
All reactions