Simon Green

It looks like it's a configurable option for Vite, but something SK manages and uses. It sets it to be generated [here](https://github.com/sveltejs/kit/blob/master/packages/kit/src/vite/index.js#L34), using it [here](https://github.com/sveltejs/kit/blob/master/packages/kit/src/vite/index.js#L157) I don't know if it's...

The name can be set (it _defaults_ to `manifest.json` if the option is set to `true`, but it can take a filename as well). So SvelteKit can control what file...

Providing some way to hook into the deserialization on the client would make it easier to convert ISO date strings back to JS Objects (i.e. as a `reviver` option to...

This is terrible and you shouldn't use it, but it can go in the hooks handle (really what you already mentioned, I realize after re-reading): ```ts const bytes = await...

One gotcha this could help avoid is when the data changes between server and client. i.e. the content contains Date objects, but then ISO format strings on the client and...

That's only a solution if access to that server data is _always_ through the matching SK front-end. Maybe you have other apps or components that would like to fetch data...

I would, if SvelteKit provided the hooks to enable it. But you get one kind of data on the server and different data (because it's been JSON serialized) on the...

I take it page endpoints are considered "framework" and liable to change at any time / shouldn't be depended on as an external API (is it worth setting headers to...

> our fetch wrapper creates a Request object from your fetch call and passes it back to the SvelteKit server to handle directly That's where the server / client inconsistency...

> What inconsistency? That you get JavaScript Date Objects during SSR but ISO 8601 format date strings after client navigation.