Fix CSS url() asset references#515
Conversation
Reproduces #513 — verifies that assets referenced via CSS url() in styled components are served correctly by the bundler.
🦋 Changeset detectedLatest commit: aa16a28 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
72e13da to
5fda1b9
Compare
The base branch was changed.
ae70f48 to
72e13da
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
|
nextjs with webpack fails because of a bug in mini-css-extract plugin which was resolved by Luca Schneider (@Mad-Kat) in webpack/mini-css-extract-plugin#1161 and merged - so we have to wait for a new next.js release with mini-css-extract-plugin 2.10.2 |
Fixes #513
Root cause: The
\0prefix on virtual module IDs prevents Vite's CSS pipeline from determining the correct directory forurl()resolution.Fix: Drop the
\0prefix and use a.yak.csssuffix instead.resolveIdnow returns/abs/path/Component.tsx.yak.css, giving Vite the correct directory context to resolve relativeurl()paths. This follows the same convention as vanilla-extract, Linaria, and Pigment CSS. Vite docs confirms that\0isn't needed for file-derived modules.Cross-file url() references: A second issue exists with
url()paths inside cross-file mixins. When a mixin is inlined into a consuming component, relativeurl()paths still point relative to the mixin's original directory, not the consuming file's directory. To fix this, relativeurl()paths are now rewritten during cross-file resolution so they resolve correctly from the consumer's location.