Skip to content

Revisit service worker modules #16159

Description

@Rich-Harris

Describe the problem

In SvelteKit 2 we have $app/*, $lib/*, $env/* and $service-worker. In SvelteKit 3 we're getting rid of $env/*. I think we should consider getting rid of $service-worker as well, since it's a bit of an anomaly. Doing so would leave just $app/* (generated modules specific to your app) and $lib/* (your stuff) alongside the @sveltejs/kit modules, which feels a bit friendlier and easier to explain.

Describe the proposed solution

It exports base, build, files, prerendered and version.

base could presumably be imported from $app/paths. At present this module can't be imported into the service worker but that feels like an unnecessary restriction. There might be some Vite footwork involved in making it work but I'm pretty sure it's possible.

build, files and prerendered could perhaps be exported from a new $app/assets or $app/manifest module. They're primarily intended for service worker caching but it's not inconceivable that they could be useful in other contexts, so making it more generic feels like a win.

version could be imported from $app/env. As with $app/paths, it's not currently available IIRC but I don't see why it shouldn't be.

Alternatives considered

not doing this

Importance

nice to have

Additional Information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    breaking changeneeds-decisionNot sure if we want to do this yet, also design work neededservice workerStuff related to service workers

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions