Summary
normalizeEmittedLazyEntries (src/index.ts#L563 on next) strips the isEntry flag from the real configured client entry when that entry chunk is itself the target of a dynamic import. Downstream tooling that scans the bundle or manifest for the entry chunk (e.g. TanStack Start's manifest capture) then fails with "No entry file found".
This graph shape arises naturally with Solid 2.0: @solidjs/web/frames/client dynamically imports @solidjs/web/serialization/decode (the lazy codec chunk, loadCodec()). If any userland or library module in the client graph statically imports that same decode module, rolldown merges decode into the entry chunk — making the entry chunk a dynamic-import target of itself. The normalization then reclassifies the genuine entry as an emitted lazy entry.
Mechanism
The normalization collects every dynamicImports target across the bundle/manifest and unconditionally clears isEntry on all of them:
function normalizeEmittedLazyEntries(manifest: Record<string, any>) {
const dynamicKeys = new Set<string>();
for (const key in manifest) {
const imports: string[] | undefined = manifest[key].dynamicImports;
if (imports) for (const dep of imports) dynamicKeys.add(dep);
}
for (const key of dynamicKeys) {
const entry = manifest[key];
if (entry && entry.isEntry) {
entry.isEntry = false;
entry.isDynamicEntry = true;
}
}
}There is no exception for a chunk that is a genuine configured entry. It runs in two places:
generateBundle on the client build (when ssr: true) — mutates the raw bundle, which is what downstream plugins see, and what Vite's own manifest plugin serializes to .vite/manifest.json afterwards (src/index.ts#L1172);- the virtual manifest
load hook, which normalizes the parsed manifest.json again (src/index.ts#L1141).
The reclassification itself exists for a good reason (chunks emitted for lazy() targets are marked isEntry by Rollup — see #269/#271), but keying purely off "is a dynamic-import target" misfires when the real entry absorbs a dynamically-imported module.
Additional wrinkle observed under rolldown: the entry.isDynamicEntry = true write does not stick on rolldown bundle chunks, so the affected chunk ends up classified as neither an entry nor a dynamic entry (isEntry=false isDynamicEntry=false).
How it was hit in the wild
In tanstack/router PR #8214, @tanstack/solid-router's client shim statically imported @solidjs/web/serialization/decode while Solid's frames client dynamically imports the same module. Three app builds failed with "No entry file found" from TanStack Start's manifest step; instrumenting it showed the entry chunk listed itself in its own dynamicImports and contained decode.js. The workaround on the router side was switching the shim to a dynamic import so decode stays in Solid's own lazy chunk — but any static import of that module anywhere in the client graph re-triggers this.
Minimal repro
Verified with the file set below (npm install && npm run build).
package.json
{
"name": "tmp-vite-entry-repro",
"private": true,
"type": "module",
"scripts": { "build": "vite build" },
"dependencies": {
"@solidjs/vite-plugin": "3.0.0-next.35",
"@solidjs/web": "2.0.0-rc.6",
"solid-js": "2.0.0-rc.6",
"vite": "8.2.2"
}
}index.html
<!doctype html>
<html>
<head><title>repro</title></head>
<body>
<div id="root"></div>
<script type="module" src="/src/entry-client.tsx"></script>
</body>
</html>src/entry-client.tsx
import { render } from "@solidjs/web";
// Brings @solidjs/web/frames/client into the graph; its loadCodec() contains
// the runtime's dynamic import of "@solidjs/web/serialization/decode".
import { getFrameHost } from "@solidjs/web/frames/client";
// The static import that merges the decode module into the entry chunk.
// Comment this line out and the entry chunk keeps isEntry.
import { createJSONDeserializer } from "@solidjs/web/serialization/decode";
getFrameHost();
render(
() => <div>static decode import: {typeof createJSONDeserializer}</div>,
document.getElementById("root")!
);vite.config.mjs
import { defineConfig } from "vite";
import solid from "@solidjs/vite-plugin";
export default defineConfig({
plugins: [
solid({ ssr: true }),
{
name: "check-entry",
enforce: "post",
generateBundle(_options, bundle) {
console.log("\n[check-entry] bundle chunks:");
for (const [file, chunk] of Object.entries(bundle)) {
if (chunk.type !== "chunk") continue;
console.log(
` ${file} isEntry=${chunk.isEntry} isDynamicEntry=${chunk.isDynamicEntry} dynamicImports=${JSON.stringify(chunk.dynamicImports)}`
);
}
const entries = Object.values(bundle).filter(c => c.type === "chunk" && c.isEntry);
if (entries.length === 0) console.log("[check-entry] ERROR: No entry file found in bundle");
else console.log(`[check-entry] OK: entry chunk(s): ${entries.map(c => c.fileName).join(", ")}`);
}
}
],
build: { manifest: true }
});Result (with the static decode import)
[check-entry] bundle chunks:
assets/index-CHRjRhVs.js isEntry=false isDynamicEntry=false dynamicImports=["assets/index-CHRjRhVs.js"]
[check-entry] ERROR: No entry file found in bundle
dist/.vite/manifest.json — the entry record has no isEntry and dynamically imports itself:
{
"index.html": {
"file": "assets/index-CHRjRhVs.js",
"name": "index",
"src": "index.html",
"dynamicImports": ["index.html"]
}
}Control (static decode import removed, same app otherwise)
[check-entry] bundle chunks:
assets/index-d8IApeq2.js isEntry=true isDynamicEntry=false dynamicImports=["assets/decode-CXlfBLa9.js"]
assets/decode-CXlfBLa9.js isEntry=false isDynamicEntry=true dynamicImports=[]
[check-entry] OK: entry chunk(s): assets/index-d8IApeq2.js
Expected behavior
The normalization should never strip isEntry from a chunk that is a genuine configured entry (e.g. skip chunks whose facade/module id matches a configured input, or skip self-referencing dynamic imports), regardless of whether that chunk is also a dynamic-import target. At minimum, it should emit a warning explaining the graph shape so the resulting "No entry file found" failures downstream are diagnosable.
Environment
@solidjs/vite-plugin 3.0.0-next.35solid-js / @solidjs/web 2.0.0-rc.6vite 8.2.2 (rolldown 1.2.7)- Node v26.4.0, macOS
Summary
normalizeEmittedLazyEntries(src/index.ts#L563 onnext) strips theisEntryflag from the real configured client entry when that entry chunk is itself the target of a dynamic import. Downstream tooling that scans the bundle or manifest for the entry chunk (e.g. TanStack Start's manifest capture) then fails with "No entry file found".This graph shape arises naturally with Solid 2.0:
@solidjs/web/frames/clientdynamically imports@solidjs/web/serialization/decode(the lazy codec chunk,loadCodec()). If any userland or library module in the client graph statically imports that same decode module, rolldown merges decode into the entry chunk — making the entry chunk a dynamic-import target of itself. The normalization then reclassifies the genuine entry as an emitted lazy entry.Mechanism
The normalization collects every
dynamicImportstarget across the bundle/manifest and unconditionally clearsisEntryon all of them:There is no exception for a chunk that is a genuine configured entry. It runs in two places:
generateBundleon the client build (whenssr: true) — mutates the raw bundle, which is what downstream plugins see, and what Vite's own manifest plugin serializes to.vite/manifest.jsonafterwards (src/index.ts#L1172);loadhook, which normalizes the parsedmanifest.jsonagain (src/index.ts#L1141).The reclassification itself exists for a good reason (chunks emitted for
lazy()targets are markedisEntryby Rollup — see #269/#271), but keying purely off "is a dynamic-import target" misfires when the real entry absorbs a dynamically-imported module.Additional wrinkle observed under rolldown: the
entry.isDynamicEntry = truewrite does not stick on rolldown bundle chunks, so the affected chunk ends up classified as neither an entry nor a dynamic entry (isEntry=false isDynamicEntry=false).How it was hit in the wild
In tanstack/router PR #8214,
@tanstack/solid-router's client shim statically imported@solidjs/web/serialization/decodewhile Solid's frames client dynamically imports the same module. Three app builds failed with "No entry file found" from TanStack Start's manifest step; instrumenting it showed the entry chunk listed itself in its owndynamicImportsand containeddecode.js. The workaround on the router side was switching the shim to a dynamic import so decode stays in Solid's own lazy chunk — but any static import of that module anywhere in the client graph re-triggers this.Minimal repro
Verified with the file set below (
npm install && npm run build).package.json{ "name": "tmp-vite-entry-repro", "private": true, "type": "module", "scripts": { "build": "vite build" }, "dependencies": { "@solidjs/vite-plugin": "3.0.0-next.35", "@solidjs/web": "2.0.0-rc.6", "solid-js": "2.0.0-rc.6", "vite": "8.2.2" } }index.htmlsrc/entry-client.tsxvite.config.mjsResult (with the static decode import)
dist/.vite/manifest.json— the entry record has noisEntryand dynamically imports itself:{ "index.html": { "file": "assets/index-CHRjRhVs.js", "name": "index", "src": "index.html", "dynamicImports": ["index.html"] } }Control (static decode import removed, same app otherwise)
Expected behavior
The normalization should never strip
isEntryfrom a chunk that is a genuine configured entry (e.g. skip chunks whose facade/module id matches a configured input, or skip self-referencing dynamic imports), regardless of whether that chunk is also a dynamic-import target. At minimum, it should emit a warning explaining the graph shape so the resulting "No entry file found" failures downstream are diagnosable.Environment
@solidjs/vite-plugin3.0.0-next.35solid-js/@solidjs/web2.0.0-rc.6vite8.2.2 (rolldown 1.2.7)