Enable package-provided routes
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 20.8k
- Forks
- 2.3k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 156
Description
Describe the problem
Please bear with me for a minute, explaining the rationale requires a bit of context.
I'm working on a (FOSS) SvelteKit-based ebook library app. It is built to run on all platforms SvelteKit supports, with platform-specific integrations being used where possible. If you'd be running it on Cloudflare, for example, the Cloudflare R2 bucket integration will be used for storage; if running on Node, it will use the local filesystem. On a platform like Netlify, which has support for edge functions, book metadata parsing will run on the edge; whereas on other platforms, it'll use a web worker for that.
In addition to platform features, there are a bunch of other modules with configurable implementations (mailing, knowledge graph queries, image uploads, etc.).
Now, to make it easier for users to get started, as well as keeping runtime size small, I have an npm create package that will prompt the user for the services they use, and perform a custom install of all required packages: Say, @example/core, @example/mailing-mailgun, and @example/storage-cloudflare (and their respective dependencies).
All of this works; what I'm missing, however, is a good way of packaging up the actual SvelteKit app in a reusable way. Right now, I have to copy all project files from a template repository into the user's project directory, install dependencies, and generate a matching .env file.
On the plus side, this gives users something of an improved git clone, essentially a glorified configuration script. They can modify all routes and components to their liking.
On the downside, this setup is incredibly hard to reliably update, and requires anything and everything to have a stable API.
Describe the proposed solution
What I envision is the ability to distribute my SvelteKit app as a dependency users would install into an empty project, along with any extension packages they need. The project would start with an empty src/routes directory; all routes would be loaded from the base application, unless a file with the same path exists in the routes directory. For example, my app would provide an implicit /profiles/[user] route, which users could eject/override by creating src/routes/profiles/[user]/+page.svelte. (Thanks to @theetrain on Discord for putting it so succinctly). Obviously this still bears the risk of ejected routes breaking after updates, but in that case it's immediately clear whether a bug is caused by userland or package code.
This would make for a very small installation footprint, while still being hackable.
From a technical POV, this would probably work best as a Vite plugin that overlays SvelteKit, as in plugins: [ kit(), app() ]. I have dabbled with Vite, but definitely not enough yet to do this on my own, however.
Alternatives considered
Having users git clone a starter repository, or copying a starter project using the create package both work, but come with the aforementioned downsides (namely the complexity of updates and support headaches).
Importance
would make my life easier
Additional Information
The project is still a work in progress, although the repository shows the structure I'm going for, if that helps:
https://github.com/project-kiosk/kiosk/tree/next#readme
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin with the proposed Vite configuration (plugins: [ kit(), app() ]) and the empty src/routes behavior described in the issue. Determine the scope and override rules for package-provided routes, then verify that a dependency can supply routes while a matching user file can replace one; the feature is done when this works without copying the starter project.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, vite
- Domain
- frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100