[GH-ISSUE #861] Support static metadata URL resolver (`fillStaticMetadataSegment`) #188

New issue

Closed

opened 2026-05-06 12:37:59 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:59 +02:00

Owner

Originally created by @github-actions[bot] on GitHub (Apr 18, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/861

Context

7873aea — Perf: Simplify static metadata handling (Next.js canary, 2026-04-17)

Next.js added a dedicated fillStaticMetadataSegment() function in lib/metadata/get-metadata-route.ts that resolves static metadata file URLs without route-regex work. Static metadata files like favicon.ico, icon.png, and other static metadata images no longer go through the generic fillMetadataSegment(..., true) path that was designed for dynamic metadata routes.

What changed

New fillStaticMetadataSegment(segment, lastSegment) function that:
- Normalizes app path segments
- Replaces dynamic and catch-all segments with - placeholder
- Preserves metadata filename suffix logic for route groups and parallel routes
fillMetadataSegment() now short-circuits to fillStaticMetadataSegment() when isStatic=true
Webpack static metadata image loader now emits the final static URL string at build time instead of generating runtime code that awaits props.params
Dev bundler uses fillStaticMetadataSegment() for static metadata file mapping

Relevance to vinext

If vinext serves static metadata files (favicon, icons, etc.) from the app/ directory, it needs to correctly compute their URLs. The new static path handles:

Root favicon (/favicon.ico)
Static metadata under dynamic parents (/blog/-/favicon.ico)
Route-group / parallel-route suffix behavior (hash-based suffixes)

The routing layer that scans app/ directories should use equivalent logic when resolving static metadata file paths.

Originally created by @github-actions[bot] on GitHub (Apr 18, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/861 ## Context [`7873aea`](https://github.com/vercel/next.js/commit/7873aeaa51cb445bc345986941934c295c63e6f1) — **Perf: Simplify static metadata handling** (Next.js canary, 2026-04-17) Next.js added a dedicated `fillStaticMetadataSegment()` function in `lib/metadata/get-metadata-route.ts` that resolves static metadata file URLs without route-regex work. Static metadata files like `favicon.ico`, `icon.png`, and other static metadata images no longer go through the generic `fillMetadataSegment(..., true)` path that was designed for dynamic metadata routes. ## What changed - New `fillStaticMetadataSegment(segment, lastSegment)` function that: - Normalizes app path segments - Replaces dynamic and catch-all segments with `-` placeholder - Preserves metadata filename suffix logic for route groups and parallel routes - `fillMetadataSegment()` now short-circuits to `fillStaticMetadataSegment()` when `isStatic=true` - Webpack static metadata image loader now emits the final static URL string at build time instead of generating runtime code that awaits `props.params` - Dev bundler uses `fillStaticMetadataSegment()` for static metadata file mapping ## Relevance to vinext If vinext serves static metadata files (favicon, icons, etc.) from the `app/` directory, it needs to correctly compute their URLs. The new static path handles: - Root favicon (`/favicon.ico`) - Static metadata under dynamic parents (`/blog/-/favicon.ico`) - Route-group / parallel-route suffix behavior (hash-based suffixes) The routing layer that scans `app/` directories should use equivalent logic when resolving static metadata file paths.