astro

Astro Info If this issue only occurs in one browser, which browser is a problem? _No response_ Describe the Bug Astro does not prune original images if they are used via a content collection. Astro already deletes the emitted source file of an image when nothing outside the image pipeline references it. does this: That works for images imported directly into a component. It never works for images that reach the build through a content collection's , because Astro's own content runtime marks every one of them as referenced before user code can touch them. is populated by the Proxy in , which records any property read: The read comes from in : 's leaves true, so the walk descends into the Proxy it just substituted and reads , , and . Each read adds the image to , and the prune in is then skipped for every content image in the project. The result is that the untouched source file of every content-collection image is shipped, whether or not anything points at it. On my site that is 138 files and 810 MB, next to the 52 MB the site actually serves — a 16× larger deploy made entirely of files no visitor and no crawler can reach. This is the mechanism behind #11887 and the residue of #8143. What's the expected result? Astro does not put the unreferenced images in the output so the deploy size is not bigger than it needs to be. Link to Minimal Reproducible Example https://github.com/wimdeblauwe/astro-content-image-original-not-pruned Participation [ ] I am willing to submit a pull request for this issue.

Changes CSS modules in the prerender build have empty — Vite extracts their content into separate assets, leaving the module's as . Because was skipping modules with no code, CSS edits never changed the dependency hash and incorrectly returned , restoring cached HTML that referenced the old, now-missing filename. When a module's code is empty and its ID matches , now reads the source file from disk and includes its contents in the hash. CSS edits now produce a different dependency hash, causing affected pages to re-render with the correct stylesheet reference. Closes #17704 Testing Added two unit tests in under : one that asserts the hash changes when the CSS file is modified on disk, and one that asserts the hash is stable when the file is unchanged. Docs No docs update needed — this fixes a bug in , which is not yet documented beyond the config reference.

Astro Info If this issue only occurs in one browser, which browser is a problem? _No response_ Describe the Bug Astro version: 7.2.1 Setup: experimental.incrementalBuild: true Content-collection route (blogs/[slug].astro) with cacheKey = entry.digest Shared Layout.astro imports src/styles/global.css Repro: 1. Build. Blog HTML references _astro/global.A.css. Asset exists. 2. Edit only global.css. Rebuild. 3. Blog routes show (cached). HTML still references global.A.css, but _astro/ only contains global.B.css. Cause: cache validity is decided from input source hashes (plugin-incremental.js → pageDependencyHashes, checked in generate.js:382). CSS-only edits change output asset hashes without changing the hashed inputs for content routes, so stale HTML is reused. What's the expected result? Cached pages re-render when referenced asset hashes change, or build warns. Actual: build green, production pages load a 404 stylesheet. Link to Minimal Reproducible Example https://github.com/JojokCreator/astro-incremental-css-repro Participation [ ] I am willing to submit a pull request for this issue.