astro

Astro Info If this issue only occurs in one browser, which browser is a problem? _No response_ Describe the Bug Hi Astro Team, When running the npm run build command in my multilingual SSG project, I encounter the following warning message: My Questions: Is this warning expected behavior under this specific configuration, or is it an internal routing bug? Is it completely safe to ignore this warning, or will it cause unexpected layout/redirection issues in a production SSG environment? Project Structure: Configuration (astro.config.mjs): Additional Context: I have tried clearing the .astro/, dist/, and node_modules/.vite/ cache directories completely before running the build command, but the warning persists. The build still outputs ✓ Completed, and the dist/en/index.html file seems to be generated, but I want to make sure this internal conflict doesn't break path normalization or edge case redirects.Thank you for your help! What's the expected result? There should be no warnings in the console output during npm run build. Link to Minimal Reproducible Example https://stackblitz.com/edit/github-vjakyqx8 Participation [ ] I am willing to submit a pull request for this issue.

Astro Info If this issue only occurs in one browser, which browser is a problem? Safari, iOS Safari — though note the built CSS itself is identical for every browser; Safari is just the only one that still depends on the prefix that gets stripped, so it's the only one where the effect is visible. Describe the Bug I found this while upgrading a project from Astro 5 to Astro 7. With completely default settings (no , no , no browserslist config), Astro silently removes a vendor-prefixed CSS declaration even though the unprefixed equivalent is written right next to it, and even though the prefix is still required by supported browsers. Source: Built output: is missing. Safari / iOS Safari still require this prefix according to browser compatibility data, so this isn't a "no longer needed" cleanup, it's a regression for Safari users. This doesn't seem specific to — I'd expect any vendor-prefixed CSS that Lightning CSS's target resolution considers "unnecessary" to be affected the same way. Investigation I traced this back with the following observations: Confirmed absent on Astro and — both preserve the prefix. Reproduces starting at Astro 7 (Vite 8), where Lightning CSS became the default CSS minifier instead of esbuild. I instrumented Vite's during a real on the unmodified default project (see reproduction link below), and logged the actual value being passed to Lightning CSS: So resolves to , and Vite's helper discards entries, producing an empty (but present) object. Calling 's API directly with the same CSS and varying only the value: This suggests Lightning CSS treats an empty as "no browser needs any compatibility accommodation," which would explain the removal. As for where the value comes from: sets for the static/prerender build (reasonable, since that build's JS runs in Node). Vite's own default resolution () then has inherit that same value unless overridden. I believe this is how the JS-oriented target ends up affecting CSS that's actually served to the browser. Workaround Setting explicitly in avoids the empty-targets fallback and restores correct prefixing: Possible directions (not trying to prescribe the fix): Avoid inheriting into for this build config, since the CSS it produces is browser-facing even though the JS is not. Default for this build to a browser-oriented baseline (e.g. Vite's own default, or the project's ) instead of the JS target. Related issues Not the same as #17225 / #17226 — those only reproduce when / is explicitly set to . This reproduces with fully default settings. Related to vitejs/vite#20505 ("Inconsistent value, leading to duplicated CSS", open), which reports a JS-oriented leaking into in a cross-environment (client vs. SSR) form. This looks like a same-environment instance of the same underlying issue, surfaced through Astro's prerender build config. What's the expected result? Both declarations should be preserved (or at least the prefix should not be removed unless it's genuinely unnecessary for the browsers being targeted). Astro should avoid letting the JavaScript-oriented build target used for the static/prerender build affect the CSS compatibility target for CSS that is shipped to the browser. Link to Minimal Reproducible Example https://github.com/klim0824/astro-css-prefix-repro Participation [ ] I am willing to submit a pull request for this issue.