Fix manifest not being JSON.parse-able (missing "")
See original GitHub issueDescribe the problem
In most adapters, the builder generates a list of assets, entry files, and routes using builder.generateManifest.
However, the generated dictionary (it’s a string type, but in dictionary format) is not JSON spec-compliant; it can’t be JSON.parsed or otherwise read without exec because the dictionary keys are missing double quotation marks (").
This is a problem because this manifest can be used for other things, such as generating a _headers file for Cloudflare to use Server Push or parsing entry files for further bundling in adapters.
Describe the proposed solution
The most clear solution, in my mind, is to add double quotes (") around each dictionary key.
This is still valid Javascript so it won’t break scripts that inject it as-is into JS files. This solution would allow parsing using standard functions such as JSON.parse
Alternatives considered
An alternative could be to not change this and parse using exec etc. However, this is much easier to break than spec-compliant JSON.parse and doesn’t function in some environments.
Importance
would make my life easier
Additional Information
No response
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)

Top Related StackOverflow Question
Yeah, it sounds like this is probably best solved in userland, so I’ll close this. Generally speaking you can’t know which assets to push until you’ve actually rendered the page, and I doubt SvelteKit could generate that list in a way that improved performance universally (I haven’t used server push, but my understanding was that it didn’t work very well in the wild because it’s easy to misuse bandwidth; Early Hints seems more promising but only has so much value when the HTML is already generated).
You could probably do something grotesque like this, if it improves performance:
I was planning to based on extension (so .jpeg, .jpg, .png, etc) but I guess that wouldn’t ensure that it’s scoped to the current page (even if I tried directly in the adapter it would grab all the assets, not just the current page’s assets).
In my mind one solution would be returning Link headers in the GET inside a Shadow Endpoint, but that’s again running into the issue of filenames being dynamically generated… except that
vite-imagetoolsconverts the imports to the URLs at build-time so it might allow returning inside aloadfunction, which I didn’t think of before.Might not be possible for all tools, but this does seem like a niche use-case. In that case, free to close this issue 🙂