[13.x] Index Vite manifest chunks by output file

[atymic]

Resolving a CSS file back to its manifest entry currently scans the whole manifest, once per CSS reference, inside the recursive walk over dynamic imports. Three sites do it, two via where('file', $css) and one via first(fn ($chunk) => $chunk['file'] === $css).

Cost is entries × css_refs × imports. On the manifest I hit this on (434 entries, 145 CSS references, an entrypoint declaring 125 dynamic imports) that's roughly 63k comparisons per render, paid on every request that renders @vite(...). I found it on Lambda where the call was taking ~54ms.

This builds the file -> key index once per render and looks chunks up directly.

The index is a plain local, not a static cache. All of the win comes from reusing it across the ~145 lookups within one render, so persisting it between requests measured no faster and would have meant a second never-cleared static next to $manifests. chunkKeysByFile() keeps the first match on a duplicate file value, matching where(...)->first().

Benchmarks

Real Illuminate\Foundation\Vite, 430 entry manifest, 30 iterations, median. There's no benchmark suite in the repo so this is a standalone script, happy to share it.

Case	Before	After	Speedup
entrypoint, 125 dynamic imports	2.170 ms	0.175 ms	12.4x
entrypoint, 142 dynamic imports	3.566 ms	0.214 ms	16.7x
all four entrypoints	11.317 ms	0.419 ms	27.0x

Output is unchanged

Rendered HTML plus preloadedAssets() across 5 entrypoint combinations × 3 prefetch strategies, diffed against a pristine copy of the class: 498,317 bytes, byte identical. The fixture includes a duplicate file value to cover the first-match rule.

Two tests added, both passing before and after, there to lock in existing behaviour rather than demonstrate a fix. One asserts tags and preloads for CSS reached through nested imports (the existing testViteWithNestedCssImport only covers CSS with no manifest entry of its own, and doesn't check preloads). The other pins the first-match behaviour.

[github-actions]

Thanks for submitting a PR!

Note that draft PRs are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.