The `$service-worker` module should categorise all files generated by type, not by origin

Describe the problem

As you know, SvelteKit already categorises all generated files into three categories: build, files and prerendered. These are based on the origin of the files, which, from a coders perspective, makes sense and is easy to implement. But the thing is, in most environments it does not matter from where a file originates, but much rather what the content of the file actually is.

Take for example the simplest SvelteKit application (without disabling hydration) that you can think of. A prerendered version of it would only consist of a couple .html and .js files. Now if a developer would want to prefetch and cache all hydration related assets that would be doable by using the build array (since Vite generated them) exported by $service-worker. But this setup quickly falls apart when anything other then scripts gets imported into a svelte component. Added a picture? You have to resort to client-side filtering to not waste bandwidth. Added a stylesheet? Again, you have to resort to client-side filtering. Client-side filtering obviously comes with the caveat that the whole build array would still be shipped, even if it's filled with a morbillion epic memes.

Describe the proposed solution

I present to you "categorisation by type":

import { version, pages, scripts, styles, images, plaintext, binary, other... } from "$service-worker"

Making the developer cherry-pick their required files allows for much better tree-shaking (pun not intended). The actual categories should be tweaked if this idea actually gets adopted.

Alternatives considered

I just came up with an alternative to my proposed solution: Making scripts "prerenderable" (for instance using a query) which would execute the code only once on the server, then get all exported variables and finally send them to the client, without the code that constructed them (just like prerendered pages without hydration). In this context that would allow developers to get an array without any client side code, which could just be passed to cache.addAll. But of course this type of feature would require a lot of work, discussions, streamlining etc.

Importance

nice to have

Additional Information

No response

Start at the $service-worker module and review how its existing build, files and prerendered arrays are assembled. Compare the proposed content-based categories and tree-shaking behavior, then determine the category set and export design needed to let developers select scripts, styles, images and other generated files.