(fix #21456): ensure css-only entries are marked as isEntry

[DsChauhan08]

Fixes a bug where CSS-only entries were not marked as 'isEntry: true' in the manifest when using array-based input. This resulted in missing entry points for pure CSS files.

Changes:

• Added a 'writeBundle' hook to 'native:manifest-compatible' plugin in 'packages/vite/src/node/plugins/manifest.ts'.
• The hook patches the manifest file on disk to ensure all input files are correctly marked as entries.
• Fixes path resolution for manifest file using 'outDir'.

Verification:

• Added reproduction test case 'manifest-css-entry'.
• Verified regression tests pass.

[sapphi-red]

Would you explain why this happens?

[DsChauhan08]

This happens because with array-based input, Rollup can treat CSS-only inputs as “assets” rather than JS entry chunks.
the manifest entry is emitted without isEntry: true, so pure CSS inputs don’t show up as entries. The writeBundle hook patches the manifest after generation to ensure all inputs (including CSS-only) are marked as entries.

[sapphi-red]

Rollup can treat CSS-only inputs as “assets” rather than JS entry chunks.

Why does this happen?

[DsChauhan08]

With array-based input, the CSS entry files that contain only @import statements get processed into "pure CSS chunks" (chunks with no JS exports). When the CSS post-plugin emits these as assets and registers them in cssEntriesMap, the key used is chunk.name. However, for array-based input, the name derivation may not produce a key that matches the manifest entry key (which is derived from src). With object-based input, the explicit key name is used consistently throughout, so the lookup succeeds. This patch ensures any input file present in the manifest gets marked as an entry regardless of the chunk naming.

i could have tried fixing using Ensure the cssEntriesMap key is derived consistently between the CSS plugin and manifest plugin Or normalize input arrays to objects early in the build process to ensure consistent naming
but for the moment being the way i fixed seemed the best, maybe if other cases arise we could test the other fixes?

[DsChauhan08]

adding to that : The root cause is a mismatch in how CSS entry chunks are keyed between the CSS plugin and the manifest plugin.

When a CSS entry file contains only @import statements (no actual CSS rules), it becomes a "pure CSS chunk" (isPureCssChunk = true). In the cssPostPlugin, when this chunk is emitted as an asset, it gets registered in cssEntriesMap using chunk.name as the key:

cssEntriesMap.get(this.environment)!.set(chunk.name, referenceId)
Later, the manifest plugin tries to look up entries using entryCssAssetFileNames.get(chunk.fileName) to get the name and mark entries with isEntry: true.

The issue is that with array-based input, the chunk.name for pure CSS chunks may not be derived the same way as with object-based input:

Object input { 'main-css': 'src/main.css' } → chunk.name = 'main-css' (explicit)
Array input ['src/main.css'] → chunk.name is derived from the file path, but for import-only CSS files, this derivation can differ from what the manifest expects
This is why the lookup in createAsset() fails to find a matching name, so isEntry never gets set.

Two possible approaches:

1.Patch the manifest (current approach) - after manifest generation, check if any src matches an input file and mark it as isEntry
2. Fix the root cause - ensure cssEntriesMap uses a consistent key that matches how manifest entries are keyed (e.g., use the normalized source path instead of chunk.name)

Would you prefer I investigate option 2 for a more fundamental fix, or is the patching approach acceptable for this regression?