fix(html): don't inline preload link targets (fix #13355)

[kakiuwang-ui]

Description

A <link rel="modulepreload"> whose target is smaller than build.assetsInlineLimit gets rewritten to a data: URL at build time:

<!-- source -->
<link rel="modulepreload" href="/worker.js" />

<!-- built -->
<link rel="modulepreload" href="data:text/javascript;base64,Ly8gcmVmZXJl..." />

That data URL is a different module specifier from the emitted chunk, so the browser warms a module nothing else on the page will request. The preload becomes a silent no-op.

Cause

In html.ts, a link[href] that isn't a CSS request falls through to processAssetUrl(url, shouldInline) with shouldInline === undefined, which leaves the decision to the default size heuristic. There is already a noInlineLinkRels set for rels where inlining is wrong (icon, manifest, ...), and modulepreload belongs in it for the same reason.

Fix

Add modulepreload to noInlineLinkRels.

Scope

Covers modulepreload, preload and prefetch (preload/prefetch added on review request).

For preload this needed one extra thing: <link rel="preload" as="image" imagesrcset> is handled by the srcset branch, which called processAssetUrl without a shouldInline argument and so ignored noInlineLinkRels. The no-inline decision is now hoisted out of the src branch so both use it.

<link rel="preload" as="style" href="x.css"> is untouched — the isCSSRequest check above converts it into a CSS import before reaching this code.

#13355 also mentions that the emitted file is the unminified original, i.e. it never went through the JS pipeline at all. That's a distinct problem (related: #9952) and isn't addressed here.

Tests

Added links to the assets playground covering all four cases — modulepreload href, preload href, preload imagesrcset, prefetch href — pointing at files well under that playground's assetsInlineLimit: 8000, so they are inlined without the fix.

Each fails on main with the reported symptom, e.g.:

AssertionError: expected 'data:text/javascript;base64,Ly8gcmVmZ…' to match /\/foo\/bar\/assets\/preload-module-…/
AssertionError: expected 'data:image/png;base64,iVBORw0KGgoAAAA…' to match /\/foo\/bar\/assets\/preload-asset-…/

and passes with the fix, in both serve and build mode.

fix #13355

[bluwy]

preload and prefetch are broken the same way, but they overlap with #16269, so I left them out to keep this reviewable — happy to follow up separately if you'd prefer them handled together.

I think we can fix these together. Can you add them in this PR?

[kakiuwang-ui]

Done — preload and prefetch are in now, and thanks for applying the comment suggestion.

While adding them I found the fix wasn't complete for preload: <link rel="preload" as="image" imagesrcset> is handled by the srcset branch, which called processAssetUrl(url) with no shouldInline argument, so it never consulted noInlineLinkRels at all. Confirmed against a build before the change:

<link class="preload-imagesrcset" rel="preload" as="image"
      imagesrcset="data:image/png;base64,iVBORw0KGgoAAAAN..." />

So I hoisted the no-inline decision out of the src branch to the top of the for (const attr of assetAttributes) loop and passed it to both. Happy to drop that part if you'd rather keep this PR to href only.

Tests now cover href for preload/prefetch plus the imagesrcset path; all three are inlined without the change and emitted as files with it.

One thing I did not touch: <link rel="preload" as="style" href="x.css"> never reaches this code, because the isCSSRequest(url) check above it converts the link into a CSS import first. That looked like pre-existing behaviour rather than something to change here.