Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lightningcss does not resolve url() inside an astro scoped style #11060

Closed
1 task
jpcano opened this issue May 16, 2024 · 8 comments · Fixed by vitejs/vite#17364
Closed
1 task

Lightningcss does not resolve url() inside an astro scoped style #11060

jpcano opened this issue May 16, 2024 · 8 comments · Fixed by vitejs/vite#17364
Labels
ecosystem: upstream Upstream package has issue needs triage Issue needs to be triaged

Comments

@jpcano
Copy link

jpcano commented May 16, 2024

Astro Info

Astro                    v4.8.4
Node                     v18.18.0
System                   Linux (x64)
Package Manager          unknown
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

I am using the CSS attribute background-image: url('path_to_image'); in a div inside an Astro's scoped style.
lightningcss resolves the URL of the image pointing to an inexistent file in the server (ie, "/Z1Mtyq" in the reproducible example I attached) and therefore the background image is not displayed.

If I use it in a global style, the URL of the image is resolved correctly and works as expected.

What's the expected result?

I expect lightningcss to resolve the URL in a scoped style like Astro does when I am not using lightningcss

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-5pmcku?file=src%2Fpages%2Findex.astro

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label May 16, 2024
@matthewp
Copy link
Contributor

@bluwy I believe that LightningCSS does not resolve relative to the current file but rather from the root and that's the limitation being seen here. Is that correct?

https://github.com/withastro/astro/blob/464b0a108ecd0b77e6e34829381ccd1335d525ce/packages/astro/src/core/compile/style.ts#L27C25-L27C38

@bluwy
Copy link
Member

bluwy commented May 31, 2024

It's a bug in Vite while preprocessing the CSS. The urls should be left intact and not be resolved while preprocessing. But it will be resolved later by Vite in a separate pipeline. I submitted a fix upstream.

@jpcano
Copy link
Author

jpcano commented May 31, 2024

@bluwy Thank you for submitting the patch. Do you know if there is any way to make url() work with the latest Astro version without waiting for your patch to be merged?

@jpcano
Copy link
Author

jpcano commented May 31, 2024

I answer myself: One option is to move all the url() statements from the scoped styles to the global stylesheet as I showed in a comment on my stackblitz example.

@bluwy
Copy link
Member

bluwy commented May 31, 2024

You can also patch Vite with the fix I made to make it work at the meantime, as after the fix is merged upstream, it would go into Vite's 4.3 beta, so you may have to wait longer (unless you're also ok with using beta). At the moment, there's not much Astro can do itself.

@matthewp matthewp added the ecosystem: upstream Upstream package has issue label Jun 11, 2024
@matthewp
Copy link
Contributor

Closing since this is an upstream issue that will be fixed when it's fixed there.

@bluwy
Copy link
Member

bluwy commented Jun 11, 2024

It's also backported to Vite 5.2.13

@jpcano
Copy link
Author

jpcano commented Jun 11, 2024

It's also backported to Vite 5.2.13

I think your fix has been ported to Vite 5.3.0-beta.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ecosystem: upstream Upstream package has issue needs triage Issue needs to be triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants