sveltejs / sveltejs/kit

Static route configs

Open
#4,578 0 comments 0 reactions 0 assignees View on GitHub

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

Named layouts and pattern matching are amazing new features that are adding a ton of value to SvelteKit, and I'm very excited about them in general! However, the filesystem is starting to get a bit crowded overall:

/[id=integer]@blank.svelte
/[username=string]/update@modal.svelte
/profile@blank.svelte

It is unlikely that many apps will start to have this level of complexity very quickly, but I could see this becoming pretty difficult to manage in time. It also has the downside that any change to one of the configuration values will probably mess with the git history a decent amount, and if we ever want to add additional configuration options here... well, we're pretty much at the limit syntax-wise as is IMO.

Describe the proposed solution

I'm not sure if this has been thought about or suggested, but I couldn't find it in my (brief) search through issues.

As I understand it, the main reason that filenames are being used over a config within the file itself is that the contents of the file are not static - they must be executed to figure out what they actually are. So in order to build the app, we would need to run the app, which doesn't really work out 😅

An alternative way this could be solved is by adding a new top level script context. This context would use a static language, such as JSON, so that the contents would be fully statically known ahead of time:

<script lang="json" context="route">
  {
    "layout": "blank",
    "pattern": "integer"
  }
</script>

This context could be parsed out independently from the rest of the file, solving the static analysis problem. It could also potentially be accessible at runtime somehow, but then it would be both a SvelteKit and a Svelte concern (though it might already be one, tbh).

This could be added in the future, as an alternative to the filename syntax. It's fully additive, and given the complexity of adding a parsing step and figuring all of the details of that out, it may make sense to hold off and focus on other concerns first.

Alternatives considered
  • Keep the existing filename based solution.
  • Add the syntax/feature to Svelte first instead of SvelteKit (would still need a separate parse step for SvelteKit even if it had runtime semantics, since the whole point is to not run the rest of the file).
  • Have a global config, or adjacent json files. Seems like a worse solution overall, it would mean having to keep multiple files in sync when they are ultimately related.
Importance

would make my life easier

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review SvelteKit's existing filename-based named-layout and pattern-matching route configuration, using the examples in the issue as the starting point. Define how a top-level JSON route context would be parsed independently and how it would coexist with the existing syntax; the issue does not identify files, tests, or a settled completion criterion.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.