URL fragments
romainmenke opened this issue · 3 comments
How do you handle url fragments when bundling?
Scenario 1 :
file names :
style.css
a.css
style.css contents :
@import url("./a.css#foo");Do you inline a.css for url("./a.css#foo") ?
Scenario 2 :
file names :
style.css
a.css#foo
style.css contents :
@import url("./a.css#foo");Do you inline a.css#foo for url("./a.css#foo") ?
Scenario 3 :
file names :
style.css
a.css
a.css#foo
style.css contents :
@import url("./a.css#foo");Do you inline a.css for url("./a.css#foo") ?
Or do you inline a.css#foo ?
My current assumptions:
- URL fragments are invisible for bundlers, just as they are for web servers
- a file named
a.css#foois not a file with.cssextension
I would say that 1 is inlined and 2 is not.
For Scenario 3 only a.css is inlined and a.css#foo is "unreachable".
@evanw esbuild does something interesting here.
It ignores url fragments but only when there isn't a file named a.css#foo.
If such a file exists. It errors with No loader is configured for ".css#foo".
Maybe a trivial fix?
Thanks for the heads up but this doesn't really seem like a bug to me. Import paths in the browser can only be URLs but import paths for a bundler can be other things besides URLs (e.g. file paths or plugin-specific syntax). For example, bundlers may support @import "C:\\style.css"; on Windows even though that wouldn't ever work in a browser. So this behavior you're observing is sort of just a natural result of esbuild supporting a union of URL syntax and file path syntax and I don't think it needs to be "fixed". Also I doubt this edge case will ever realistically come up in practice. I'm inclined to leave esbuild's behavior as-is here.
I agree that this will never come up.
And even if it does it will almost certainly be the result of a typo.
I am going to classify this scenario as "irrelevant"