astro

Astro Info Additional version information: pnpm 12.21.0 unifont 1.0.3 (resolved as a dependency of Astro) 5.3.0 If this issue only occurs in one browser, which browser is a problem? Not applicable. This occurs before opening a browser because fails. Describe the Bug Follow-up to #16218, as requested in this comment. With unifont 1.0.3, the npm provider now returns local file: URLs, but Astro 7.4.12 still fails to read them. When attempting to bundle fonts from the installed package using , the build fails with even though the local WOFF2 file exists. The font name is set to , matching the CSS in the package. In this minimal setup, no warning about a missing font family is generated. Details Steps to Reproduce Place the following three files in an empty directory. The dependency resolution during verification was -> . For installation, was executed using the cache. The subsequent resulted in the following error: Project paths and elapsed time in the log have been omitted. The actual URL on Windows was . Suspected Cause Unifont's npm provider explicitly states that it returns installed fonts as URLs when is set, and its implementation returns . unifont's npm provider On the other hand, Astro's reads files only when from returns true, and passes everything else to . Since URLs do not pass this absolute path check, is used to load local fonts, which I believe is the cause. The same handling was present in Astro's main branch at the time of investigation. Astro's CachedFontFetcher Confirmed Workaround Wrapping of the npm provider within the Astro configuration to convert URLs in each font's to absolute file paths using allowed the build to succeed with the same minimal reproduction. It was also confirmed that 7 WOFF2 files were output. (Reproduction on Linux/macOS, the specific Astro/unifont version where the issue first occurred, and reproduction by building Astro's main branch have not been verified.) What's the expected result? Astro should load local fonts returned by the npm provider configured with , allowing the build to succeed without setting up an extra wrapper and ensuring WOFF2 files are included in the output. When a URL is received, please check the handling of font fetching and any preceding URL handling so that it can be treated as a local file. Link to Minimal Reproducible Example https://github.com/tats-u/astro-npm-local-font-repro Participation [ ] I am willing to submit a pull request for this issue.

Changes Fixes #18744 In , using a custom Cloudflare Worker entrypoint with and the documented companion handler: caused every page with to return . Root Cause 1. In production, prerendered pages are emitted as static assets, and serves them. 2. In , static assets have not been built to disk. constructed from a bare request in a custom entrypoint lacks pre-populated render options, so it resolves routes with the production matcher which skips prerendered routes when is true, falling back to the 404 route. 3. The adapter's default entrypoint calls in dev mode, which allows prerendered routes. Solution In , when , match the request pathname using and assign . Added changeset ( patch). Testing Verified with the reproduction from #18744: In , visiting () returns 200 with rendered page content instead of 404. On-demand SSR routes () and fallback asset handling continue to function as expected. Docs No documentation changes needed.

Astro Info Also reproduces with ( CLI 1.0.0-beta.32, with ). If this issue only occurs in one browser, which browser is a problem? _No response_ Describe the Bug With a custom Worker entrypoint that uses the Cloudflare companion handlers exactly as documented in Using advanced routing → With the Fetch API, every page with returns 404 in . On-demand pages work, and the same project works after + . has , , and is the documented example: Results, same project, only the entrypoint changed: Versions I tried: with and with ; both behave the same. I didn't find unreleased changes on or touching these files. The dev server logs nothing beyond , and the 404 page is returned. Possible cause (a guess from reading the source, not verified with a fix):** in dev the adapter's default handler resolves the route with and passes it to (), which is also how gets via the render options on the request. A built from a bare request in a custom Worker entrypoint has no render options, so it matches the route itself, and drops prerendered matches when is true. That's correct in production, where those pages are served as static assets, but in dev they don't exist as assets yet. has no dev-specific matching, so nothing fills the gap. What's the expected result? The documented custom Worker entrypoint ( + + , or the Hono equivalent) renders prerendered pages in the same way the adapter's default entrypoint does, returning 200 for in the reproduction. Link to Minimal Reproducible Example https://github.com/alexanderniebuhr/astro-cloudflare-fetch-dev-404-repro Participation [ ] I am willing to submit a pull request for this issue.