Simpler filesystem-based routing

[Rich-Harris]

In SvelteKit today, src/routes/about.svelte and src/routes/about/index.svelte are equivalent. The consequence of that design decision is that every component or JavaScript module inside src/routes is treated as a page or endpoint.

This creates ambiguity (is one of about.svelte and about/index.svelte more 'correct'?), and confusion — I've seen cases where people innocently had things like this...

src/routes
  index.svelte
  ComponentImportedByIndex.svelte

...not realising that they were creating a /ComponentImportedByIndex route. If you understand how Kit's routing works, it's easy enough to make files 'private' by prefixing them with _ (or putting them inside a _-prefixed directory, or giving it some other filename that causes config.kit.routes to return false), but this is ugly at best.

I'd like to propose a scheme that I think is simpler, easier to learn, unambiguous, and more aesthetically pleasing. I realise this makes certain things more verbose, and would be an annoying breaking change for some people. Please take a breath before replying with something melodramatic! I strongly believe this will be a major improvement in the long run.

Proposal

Edit: now that the Next.js routing RFC is public, I can acknowledge that this is shamelessly stolen from there

The basic idea is to only use directories to define routes:

src/app/
├ blog/
│ ├ [slug]/
│ │ ├ index.svelte
│ │ ├ index.js
│ │ └ ComponentImportedByBlogPage.svelte
│ └ index.svelte
└ index.svelte

Instead of index.{js,svelte}, it may be more explicit to use route.{js,svelte}. See 'Unresolved questions', below

The hierarchy is immediately clearer than with blog/index.svelte and blog/[slug].svelte, and we don't need to do anything weird with <ComponentImportedByBlogPage>. Things naturally group together better.

A weird thing we currently support is things like src/routes/blog/index.json.js to define /blog.json, as an alternative to using page endpoints. In this model, you'd have to do this instead...

src/app/
├ blog/
│ ├ [slug]/
│ │ └ index.svelte
│ ├ [slug].json/
│ │ └ index.js
│ └ index.svelte
├ blog.json/
│ └ index.js
└ index.svelte

...which is more verbose, but much clearer (since /blog and /blog.json are in fact separate routes, and you don't need to understand the hidden rules around foo/index.ext.js contractions).

Today, the fact that any component can be a page means that we have to prefix layout and error components — __layout.svelte and __error.svelte. With this proposal, that's no longer the case — we can do this instead:

src/app/
├ blog/
│ ├ [slug]/
│ │ ├ error.svelte
│ │ ├ index.svelte
│ │ ├ index.js
│ │ ├ layout.svelte
│ │ └ ComponentImportedByBlogPage.svelte
│ ├ error.svelte
│ ├ index.svelte
│ └ layout.svelte
├ error.svelte
├ index.svelte
└ layout.svelte

I find this much nicer. It does bring one downside though — we can no longer introduce new 'special' files without it being a breaking change (e.g. if we introduced route-level config, and someone had a config.js module, it would conflict). We would therefore need to think carefully about what names we wanted to reserve (e.g. hooks, middleware, config etc alongside index, layout and error).

Sidebar: The order of files isn't perfect. It feels like the index file should be either first or last in the directory, but the Latin alphabet is getting in the way. If we used route instead of index it might be nicer (error -> layout -> route), but in any case these files will end up interleaved with random modules and components, so maybe it's not the thing to obsess over.

If we did want to obsess over it though, one way to keep everything separate could be to keep the __ prefix but apply it to the route itself as well — __error, __layout, __route etc. This would also guarantee forward compatibility. I think that would look pretty ugly in the common case where you don't have a lot of other files in a route directory though.

Generated types

We currently take advantage of the __ prefix by writing generated types to __types/[basename].d.ts:

// src/routes/path/to/foo.ts
import type { RequestHandler } from './__types/foo';

If we were to get rid of __layout and __error in favour of layout and error, we could change this to $types, which looks nicer and is arguably more consistent with how $ is used elsewhere (__layout and __error are things you create, whereas __types is something SvelteKit creates; $app on the other hand contains partly generated modules, and $ is used generically for 'built-in alias' which ./$types qualifies as (since it uses rootDirs which is a form of aliasing).

// src/app/path/to/foo/index.ts
import type { RequestHandler } from './$types';

Note also that it's always ./$types, never ./$types/foo, which again is much nicer. This is another advantage of treating directories as routes rather than files.

Named layouts

Named layouts would work as they currently do. (An earlier version of this comment suggested adding the @foo suffix to the directory instead of index@foo.svelte etc, but that doesn't work because it would prevent child routes from bypassing layout-foo.) A nice benefit of moving to directories-as-routes is that we don't need to worry about escaping the @ character in cases where you do want it as part of your route (like @[username]).

Unresolved questions

• Should it be index.{js,svelte} or route.{js,svelte}, or something else? 'If a directory contains a route file it's a route' is a nice simple rule, though index is very conventional. Then again, the convention might work against us, since people will always want to do things like utils/index.js and not have it mean 'create a utils route'.
• If we did choose route.{js,svelte}, then src/app might feel nicer than src/routes, and in fact that's what I've used in the examples above. See Rename src/routes to src/app #3021 for a lengthy discussion on that topic

[Rich-Harris]

Edit: a lot of people were confused by this example, so to be clear: lib isn't going anywhere. It's removed from the example below to demonstrate that most of the time you can simply co-locate components with the routes that use them.

As an example, this is what the default template might look like:

before                          after

src/                            src/
├ lib/                          ├ app/
│ ├ header/                     │ ├ about/
│ │ ├ Header.svelte             │ │ └ index.svelte
│ │ └ svelte-logo.svg           │ ├ todos/
│ └ Counter.svelte              │ │ ├ api.js
├ routes/                       │ │ ├ index.svelte
│ ├ todos/                      │ │ └ index.js
│ │ ├ _api.js                   │ ├ Counter.svelte
│ │ ├ index.svelte              │ ├ Header.svelte
│ │ └ index.js                  │ ├ layout.svelte
│ ├ __layout.svelte             │ ├ index.svelte
│ ├ about.svelte                │ └ svelte-logo.svg
│ └ index.svelte                ├ app.css
├ app.css                       ├ app.d.ts
├ app.d.ts                      ├ app.html
├ app.html                      └ hooks.js
└ hooks.js

We no longer really need the lib directory in this case, since the components used by the index route can just go in src/app. The root index.svelte and layout.svelte are sandwiched between the files that previously went in lib; I don't know how I feel about that.

[mrkishi]

I think the layout and route get too obfuscated amongst regular files. The current system is confusing for other reasons, but at least you learn pretty quickly that every file represents a route unless prefixed by _.

With plain files, one would have to know each special file name by heart. Just looking at a folder a newcomer has no way to tell which file has superpowers other than previously knowing that each of layouts/hooks/middlewares/what-have-you are a thing.

[georgecrawford]

I like this, but I think I'd be most tempted by a halfway house - keep __error and __layout as reserved keywords which have particular superpowers, but leave route.{js,svelte} as the unambiguous focus of the directory; the files which provide the route's response.

[Rich-Harris]

Just realised that while I really like this...

-// src/routes/path/to/foo.ts
-import type { RequestHandler } from './__types/foo';
+// src/app/path/to/foo/index.ts
+import type { RequestHandler } from './$types';

...it doesn't solve the problem we currently have around layout types not exposing child parameters. Layouts should be able to 'see' all the parameters of their children and parents, whereas leaves should only be able to see parameters of their parents:

# file                  # visible parameters
src/app/
├ [a]/
│ ├ [b]/
│ │ ├ [c]/
│ │ │ ├ index.svelte    a, b, c
│ │ │ └ layout.svelte   a, b, c
│ │ ├ index.svelte      a, b
│ │ └ layout.svelte     a, b, c
│ ├ index.svelte        a
│ └ layout.svelte       a, b, c
├ [x]/
│ ├ [y]/
│ │ ├ [z]/
│ │ │ ├ index.svelte    x, y, z
│ │ │ └ layout.svelte   x, y, z
│ │ ├ index.svelte      x, y
│ │ └ layout.svelte     x, y, z
│ ├ index.svelte        x
│ └ layout.svelte       x, y, z
├ index.svelte
└ layout.svelte         a, b, c, x, y, z

For that we could introduce something like this:

// src/app/path/to/foo/layout.ts
import type { RequestHandler } from './$types/all'; // or `$types/layout` or something

[wiverson]

How about just generating an error or warning when a duplicate route is found?

I think that having a file in routes is pretty darn clear as to intention. Only other convention that leaps to mind is:

/lib -> no routes generated
/api -> exposes as API endpoints only
/routes -> as existing

The only other convention that I would like to see added myself is that the matcher defaults to case-insensitivity with a redirect default. e.g. /routes/ToDo.svelte would redirect to todo.svelte as an option.

Having every file named index.svelte or Index.svelte seems like it would be very frustrating and confusing to work with.

[richarddavenport]

Honestly, I really love the current conventions. It's quite easy to understand any file under routes is, well... a route. I can totally understand newcomers confusion, but then again the docs are quite nice. My one gripe with going to folder based routes and using index.{js,svelte} or route.{js,svelte} is having a lot of files all named the same. When I was on react teams that used the folder based approach for components (Components/Button/index.tsx) It was not fun! I don't have a solution or alternative. I have been using sapper and now sveltekit, so things feel easy for me currently.

[jro66]

I personally would hate it if all the open file tabs in VS Code say 'index.svelte'. I deliberately leave files in the routes directory for this very reason and I can't be the only one.

Yup this is me also, much prefer to have the name match the route. Otherwise I'm cool with the folder based approach. Maybe just keep the __layout prefixes to avoid clashes? I dont mind having the separation for these anyway.

[dummdidumm]

Regarding too many files with name "index": if you use the file search you can also include makes from the folders leading up to the name. So if you have foo/index.svelte you can find that file by typing foo

[firewave-remo]

You will find the file, but all open tabs are still called "index". Very annoying

[GavHern]

You will find the file, but all open tabs are still called "index". Very annoying

Yes, this is what i'm referring to thank you. It is easy to find in the file explorer but vscode will display the file as "index.html" which will make all of my routes look the same. I do believe it adds extra information if there are matching file names but it is still very inconvenient. You can always make a component in the route with a better name and then have the index just render that one component but it would be a lot easier to avoid that step to begin with.

[benmccann]

You may want to consider giving a thumbs up to the issue in the VS Code issue tracker: microsoft/vscode#41909

[vekunz]

I am not sure if I like the new variant (but it definitely has some advantages). But in any case, please do not merge the lib/ and routes/ directories. We have a very complex structure inside the lib/ directory, and it would be confusing for everyone if lib/ and routes/were merged together.

[fldsblzs]

Personally I also prefer the current distinction with the /lib and /routes folders. I'm working with a rapidly growing solution with a lot of routes and components and although I can see the benefit of moving the related parts closer together the current setup also provides a clear barrier between the pages/endpoints and other components/utilities/etc. with a manageable number of files present.

[Rich-Harris]

lib isn't going anywhere — the proposal is to have src/app and src/lib (or keep the current src/routes and src/lib if people dislike src/app). The example above just removes the lib folder because it's easier to co-locate components with the routes that use them under this proposal.

[dustsucker]

The Problem I see with this approach of naming every file index is that it can become confusing which file you are editing at the moment. And you have a little more “boilerplate”. I think the current way of splitting the lib and pages folder quite good. And if you want to use components from the same folder, there is a way too. So I think the Proposal wouldn't do much, I think i t could confuse some more because for every folder you have to ask your self is this the final route or does it have another sub route. So to see this, you have to expand another folder. This may not be a Problem for smaller sites, but for larger sites if you are searching for something and every thing is named index.svelte and hidden in extra folders it could be a problem. The only thing I think should change is the labeling on the docs so That it 100% clear that every .svelte file is a route except for files with _ as prefix.

[Rich-Harris]

I think the current way of splitting the lib and pages folder quite good

lib isn't going anywhere #5037 (reply in thread)

[arxpoetica]

This was the first problem I though of. Having multiple index.svelte files open on a larger project can be confusing. Hard to know which one is which, especially at a glance.

[lkj4]

every thing is named index.svelte and hidden in extra folders it could be a problem

IDK and depends how your open files. I use FZF and already type a few letter of the folder paired with some of index, e.g. movies/index.svelte would be found in FZF with something like moix. And in my vim status bar I have the full status bar.

I agree that this is more cumbersome and all the index.sveltes, however index is something learned over decades in this context. But then there's a discussion about route instead of index haha.

[pilcrowonpaper]

I guess it depends on if routes is going to be renamed to app (#3021). But, even with the name change, I don't see much merit in the proposal. I guess there are some benefits in having page-specific components in the same directory as the page. That said, I personally prefer having a clear distinction for their use case between /routes and /lib, and importantly, I feel like having layouts.svelte and error.svelte next to a component .svelte file next each other is confusing. SvelteKit has 2 uses for .svelte files, one for the router (like index.svelte and layouts.svelte) and one for normal components, and those are 2 different things and I think should be separated.

[Rich-Harris]

That said, I personally prefer the current clear distinction between /routes and /lib

lib isn't going anywhere #5037 (reply in thread)

[pilcrowonpaper]

I guess it's more of a discussion on whether to rename routes to app. (Isn't /src already the main directory of the app?) It doesn't make sense to go with this proposal if the directory name is kept as /routes.

I know that lib isn't going anywhere but I'm still not sure about placing routing-related .svelte files next to component .svelte files, which are vastly different and serve different purposes.

[pzuraq]

So my initial thoughts here are mostly positive. While this would be a more verbose setup for smaller apps, I think that it definitely would help larger apps at scale, it's currently weird to figure out how to conventionally add components and other related code to a route (we've been adding a _utils directory but that's not always very clean) and I think this would help to clean that up a lot. My only real gripe is that fuzzy finding would be a bit trickier (you'd have a lot of index.svelte and index.js to sort through), but that might actually be better since all routes would have this and you would develop muscle memory to search via folder name instead.

My only real issue with this proposal is actually this part:

Today, the fact that any component can be a page means that we have to prefix layout and error components — __layout.svelte and __error.svelte. With this proposal, that's no longer the case — we can do this instead:

While this is true, I'm not sure that this would actually be a good idea in practice. Today, you can quickly and easily visually grep for these special files in every route, which makes it much easier to find them when looking for them. With the new setup, it's very easy to miss these files in between others:

What if we kept a single underscore prefix for these special files, like so:

This would have three main advantages:

1. Easier to visually grep for special files
2. No need to reserve special file names, since special files would be namespaced
3. To new SvelteKit users in a pre-existing codebase, the underscore would become a visual hint. If a file is underscored in the /routes directory, that means it's a special file used by the framework. This explains why these files are not imported elsewhere, and indicates to the user that they should check the SvelteKit docs to figure out what this file does.

I also think it would make sense to do this for index as well for the same reasons, but agree that this would be a bit ugly. Personally, I would be ok with that ugliness, but I also think index is enough of a convention already that most users will intuitively understand what it means, so I think it would still work to have it be the default name and have the other files be namespaced.

[theetrain]

tl;dr - I like the current filesystem-based router since it resembles web standards more closely. Though the router is magical in some ways (such as its implementation of rest parameters and back-end functions), a user of SvelteKit who is new to web development should walk away with a better understanding of routing that is closer to web standards, and the docs do a great job in educating these standards when the filesystem itself may not do so 100% intuitively.

---

I want to highlight one of SvelteKit's principles:

Throughout this documentation, you'll see references to the standard Web APIs that SvelteKit builds on top of. Rather than reinventing the wheel, we use the platform, which means your existing web development skills are applicable to SvelteKit. Conversely, time spent learning SvelteKit will help you be a better web developer elsewhere.

Source: https://kit.svelte.dev/docs/web-standards

I think we should use this as a guiding light when discussing the proposed filesystem-based routing. It's good to take inspiration from other frameworks, though keep in mind Next.js updated their filesystem-based routing around the concept of React 18's server components. Since this is Svelte and not React, I see the current implementation of SvelteKit is more similar to Nuxt in some ways that I find to be fair:

1. pages can be named with files or directories + indexes. You have the option to use either method.
   Example:

   src/routes/index.svelte --> https://host.com
   src/routes/about.svelte --> https://host.com/about
   src/routes/pricing/index.svelte --> https://host.com/pricing
   

2. Components can be stored outside src/routes to be reusable, or can be colocated with pages by prefixing _ to component files within src/routes (Nuxt uses - prefixes to prevent files from rendering as pages)

Having said that, perhaps taking inspiration from Nuxt by separating pages and endpoints with pages/ and middlewares/ directories might help newcomers conceptualize what code runs in the front end and back end. It would be possible to introduce these directories in a backwards-compatible way to SvelteKit. I suppose SvelteKit developers already have the option to create a src/routes/api directory to house their endpoints if they want.

Disclaimer: I have not spent quality time using Svelte or SvelteKit yet, but I'm eager to watch these tools succeed.

[GavHern]

I don't like this idea personally. I feel like I already have the issue of having a bunch of files called index.svelte in my editor and it is difficult to tell them apart.

[ogrotten]

What's the goal here?

A clear "Here is what the benefits are" point has not been made.

The only nail that seems to be getting hammered here is the corner case ambiguity between page.svelte and page/index.svelte.

So there's those 2 points AND the removal of simple private scripts (_file.js), AND the workflow problem of "I now have 12 index.svelte tabs open in vscode".

But no clearly stated or even visible consequential benefit. Ok one soft benefit.

Therefore, I have to ask:

What's the real point of introducing all these potential negatives?

[vekunz]

But you could put such components and code just into the lib folder (organized into a subfolder system). We are doing this and we do not have any problems with this approach.

[ivanhofer]

doing this replicates the same folder structure you have in your routes. Keeping those structures manually in sync when you change a route is something you'll probably forget some time and then you "don't find" the components by just looking at the folder structure.

[0gust1]

Organizing components and their colocation in folders is dependent and specific on your app you're building.
The lib folder should not replicate the routes folder structure IMHO. routes defines URLs, not component trees or components organizations.

[cliveportman]

I thought prefixing filenames when you didn't want them to be a route was a conventional naming pattern anyway. Maybe that's because I've come from Yii but I doubt it's the only framework using them this way.

[ivanhofer]

Organizing components and their colocation in folders is dependent and specific on your app you're building. The lib folder should not replicate the routes folder structure IMHO. routes defines URLs, not component trees or components organizations.

It depends on the application you are writing. We have pretty unique pages where a lot of components are only used for a single page. Because we currently don't want to prefix them with "_", we replicate the routes folder structure in the "components" folder where also general components are placed e.g."Button.svelte".

[n-pn]

My current setup has ton of index.svelte files already, so I don't mind it too much. An you can config VS Code to show the file path in the tab: https://stackoverflow.com/questions/39598007/showing-path-in-file-tabs-in-visual-studio-code

Personally I like the new proposal, since it leads to less choice to made, every route now simply just xxx/index.{js,svelte}, instead of having to pick between xxx.{js,svelte} and xxx/index.{js,svelte} every time.

Also, @pzuraq proposal looks best to me, it's keeping the file order and make special files more distinguishable.

[dustsucker]

But I think having the choice to do that is important, for example if you have a route with 20-30 subpages I don't want to make a directory for every file. If this is the way you want to go, you can do that, but I prefer to have the files directly named specially with mdsvex and stuff. The only benefit of the Proposal is that accidentally exposing components is not an issue anymore, but I think that sometimes RTFM is the way to go. May be creating an option in the svelte.conf.js to enable strict routing mode or something like this or even the other way around, so make the new Proposal the default, but the old way still accessible. This would be a way I could support.

[n-pn]

if you have special characters in your routes, like @, _ you will see that preventing exposing private component is not the only benefit of this proposal.

Currently I have to pin sveltekit version to "1.0.0-next.323" because @ in folder has stopped working since version 324.

[benmccann]

You may want to consider giving a thumbs up to the issue in the VS Code issue tracker so that we can further improve the display of these files: microsoft/vscode#41909

[arxpoetica]

My first thought on this proposal was, hmm...could be quite nice to have certain files colocated with appropriate route index files. But (as mentioned above) the loss of named route files seems a pretty big disadvantage to the current system. I'm not sure, other than colocation, what other real benefit this new system provides.

[arxpoetica]

@Rich-Harris just so I'm not all "nay," what if we were to throw some convention to indicate it's an index? *._.{svelte|js} after the named route? Everything prior to .svelte or .js would (internally) be dropped and renamed to whatever_folder/index.svelte

before                          after

src/                            src/
├ lib/                          ├ app/
│ ├ header/                     │ ├ about/
│ │ ├ Header.svelte             │ │ └ about._.svelte
│ │ └ svelte-logo.svg           │ ├ todos/
│ └ Counter.svelte              │ │ ├ api.js
├ routes/                       │ │ ├ todos._.svelte
│ ├ todos/                      │ │ └ todos._.js
│ │ ├ _api.js                   │ ├ Counter.svelte
│ │ ├ index.svelte              │ ├ Header.svelte
│ │ └ index.js                  │ ├ layout.svelte
│ ├ __layout.svelte             │ ├ app._.svelte
│ ├ about.svelte                │ └ svelte-logo.svg
│ └ index.svelte                ├ app.css
├ app.css                       ├ app.d.ts
├ app.d.ts                      ├ app.html
├ app.html                      └ hooks.js

I don't actually like this recommendation, but just trying to help stir the pot of ideas. Maybe someone will think of something better but similar.

[n-pn]

You can leave your Counter.svelte/Header.svelte to lib/ as usual. There is no need to move everything to app/.
Pretty sure that the components inside app/ folder are meant for some local partial of the page that get extracted from the main index.svelte for the sake of maintainability. Keep related things together is the main point of Separation of concerns principle.

I don't understand why many people assume that lib/ folder will be removed.

Also, this approach won't work because of dynamic slug params. You can argue that you can copy exactly the same name from the folder to the file, but then it defeats the point of the whole proposal: To be able to use special characters (like @, $) in the route name without having to escape it or worry about future compatibility.

To explain more clearly, if this proposal is accepted, then you can just use @[user]/index.svelte instead of having to write %40[user]/index.svelte. The later currently doesn't work anyway.

As someone who affected by that issue, I'm all for this proposal to be accepted, and as soon as possible. Because while the issue about escape characters above will be fixed by #5056, apply decodeURIComponent everywhere might lead to some unforeseeable nasty bug.

[coryvirok]

I like the more verbose but simpler directory-based routing proposal here. And I also like, (like might be a strong word) the special file prefixes used.

Things I like about the directory-based approach:

1. 1 way of creating routes vs 2 that exist today. This decreases cognitive load as well as documentation and test cases and likely results in less compiled code.
2. Co-location of components + pages for tidiness when organizing my components that are only used on 1 page
3. Inching towards standards used in Next.js (likely). This is going to be important for adoption and to help newcomers from Next.js hit the ground running.

Reasons I prefer to keep special file prefixes, (__layout.js vs layout.js):

1. Name conflict with possible components. E.g. If I have a product that has an "Error" component that is not actually an HTTP error like a 404, I would likely want to call it Error.svelte. This is made possible by using the special prefixes for __error.svelte which is much less likely to have name conflicts with "user-land" code.
2. Extensibility. If we don't provide a way to distinguish between special files and user-land files, we back ourselves into a corner when we want to add new features to Kit. E.g. the config.js option Rich mentioned in the description.

I come primarily from a server-side background which means I care much more about the rendering pipeline from hooks -> endpoint -> layout -> page vs the way I think it works on client-side, layout (load) -> endpoint -> page (load) -> page render (???). There are a bunch of thorny SSR issues (error handling, differing code-paths between SSR vs client-rendering, stores, getSession + endpoints) that are made worse by pushing server-logic to the edges or leaf nodes in the directory structure instead of having the control flow go top down, read: server -> client. An example of this (IMO) anti-pattern is co-locating endpoints and pages in the same directory. It makes it difficult to grok the "where is my server code and where is my client code?" question. So I tend to rely on endpoints vs load() functions in order to be more explicit.

The reason I think this is related to this discussion is that I think layout endpoints, (which might have a different name) are coming soon and they're likely going to be a file that lives in the route directory. So, we'll need to both reserve namespace for it (e.g. by calling it __middlware.js or __section.js) and also try to keep in mind the added complexity that co-locating server and client code together brings.

p.s. When I was reading the Next.js RFC I was definitely hoping that Kit would follow-suit!

[ivanhofer]

I like the proposal.

The only two downsides I see are:

• having a 2-3 and more files with the same name opened inside your editor will be confusing. Mybe there exists an editor setting that makes it possible to show folder/index.svelte as the title of opened tabs?
• because of the alphabetic ordering of all files within a folder index.svelte and layout.svelte can be harder to find if someone decides to colocate all components related to that route. Prefixing every "special" file with _ (also _index.svelte) could be an option. But again _index.svelte is not what stands for web standards. Maybe an editor setting can help highlight those special files inside the file view?

Edit:
Maybe the Svelte VS Code Extension can be used to change the tab-title and highlight or reorder special files inside the file view?

[n-pn]

Maybe there exists an editor setting that makes it possible to show folder/index.svelte as the title of opened tabs?

yes VS Code already supports this.
https://stackoverflow.com/questions/39598007/showing-path-in-file-tabs-in-visual-studio-code

[GavHern]

yes VS Code already supports this.

I feel like what I would need to be okay with this change would be for the tab to not display the index.svelte part of the file and maybe for the index file to automatically open when i click on the folder in the file explorer.

[cliveportman]

We're talking about tweaking how one of the most popular IDE's works. Isn't Svelte all about the dev ex, including for getting new developers on board? This all sounds a bit crazy to me.

[benmccann]

The Svelte VS Code Extension cannot do anything at the moment. You may want to consider giving a thumbs up to the issue in the VS Code issue tracker: microsoft/vscode#41909

[speiffer829]

I don't have a ton to add other than I get what you are going for but I much prefer the current setup. This seems like a lot of overhead and frankly more confusing just to fix a problem that doesn't seem like that big of a problem. All this to avoid a mistake a dev is likely to make once, look up what they did wrong, then fix it and never make that error again. As opposed to having 200 index.svelte files which makes just makes finding the file I need at a glance harder when I have a few open. As a simpleton newbie who was drawn to Svelte for it's ease of learning I can safely say the proposed change would make it harder to learn not easier.

[machak]

introduce (mandatory) file extensions and you will solve most of your problems...let about.svelte resolve to about.svelte or about.html and you don't have a conflict with directory names/listings.....just like a file system...

[lkj4]

@Rich-Harris in general I like to obsess about small details, e.g. route instead of index, and it's usually those small details which make a DX great. But the new proposal has some pros but also some cons or rather unanswered questions. The point is that the proposal doesn't feel significantly better at the current stage but we might get there.

[lkj4]

@Rich-Harris mind to give us an update about which direction we are about to go? I ask bc I expect a huge rewrite of my codebase and I just want to be prepared...

[GavHern]

This is a late addition to this discussion but VSCode has introduced a feature where you can nest files beneath other files as if they're folders. I think this solves the organization issue. The only issue with this is that there can be naming collisions since they are technically all in the same directory but I feel like it's a healthy rule of thumb to not have two components in your entire project with the same name unless necessary for some reason. I think needing everything to be a folder creates a very messy project and defeats one strength of svelte where a lot of the work for your component is all done in one file (meaning the markup templating, script, and styling is all handled in your .svelte file which makes your directory structure a lot more simpler)

[ollyde]

This is really annoying, from the example app. Why not call it todos.svelte, the same as the directory name instead? Having 100s of index.svelte is just bad design. I guess Svelte isn't our answer after all.

[cliveportman]

It's pretty standard convention for index to be the default file in a directory.

[tnzk]

Just as another data point, Rust's module hierarchy used to adopt somewhat similar convention to this where certain modules need to be named by the names of their directory and have mod.rs to contain their implementation, until Rust 2018 Edition, at which point they reverted so it "eliminates the special name, and if you have a bunch of files open in your editor, you can clearly see their names, instead of having a bunch of tabs named mod.rs.".

[UltraCakeBakery]

I was working on a fork of sveltekit before named layouts were a thing, where the router works like this:

src
├── lib
├── layouts
│   ├── default
│   │   ├── _layout.js
│   │   └── _layout.svelte
│   └── dashboard
│       ├── _layout.js
│       └── _layout.svelte
└── routes
    ├── foo
    │   ├── _route.js
    │   └── _route.svelte
    └── bar@dashboard
        ├── _layout.js
        ├── _route.js
        ├── _route.svelte
        └── foo
            ├── _route.js
            └── _route.svelte

As you can see in the directory structure, layouts are no longer stored in the routes folder. They are now stored in the src/layouts directory. The name of the layout is the set by the name of the subfolder it is in. The _layout.js is the default layout shadow endpoint for that layout component. _layout.svelte is the actual layout component itself. Any folders inside src/layouts that do not have a _layout.svelte are ignored.

Routes are still stored in the /routes folder, but are required to have their own subfolder. The route is represented by the _route.svelte component. If you want to create an endpoint, you create a _route.js. The _layout.js file overwrites the layout shadow endpoint. Any other components inside /routes do not create a route; only subfolders with a _route.svelte do.

vscode is smart enough to also include the path to the file when you've got two _route.svelte files opened. If you close your tabs once in a while and not work with 10+ opened at once, working with this is perfectly fine.

[ollyde]

I don't see any improvement here? Wouldn't it be foo.svelte instead of "route.svelte"? You're just switching index with route here?

[UltraCakeBakery]

I don't see any improvement here? Wouldn't it be foo.svelte instead of "route.svelte"?

no, it would not. foo.svelte would not create a route. If you created a folder named foo with a _route.svelte inside of it, that would create a route.

You're just switching index with route here?

I think you glossed over parts like Any other components inside /routes do not create a route; only subfolders with a _route.svelte do.

[ollyde]

@UltraCakeBakery I know how Svelte routes work. What I'm saying is that it's kinda crappy that on large projects we have 100s of index.svelte or route.svelte files, makes working with Svelte annoying. Like I said, would have been better if the file name was the same as the route name, with the exception being the root index.

Example

src
└── routes
    ├── foo
    │   ├── foo.ts

[UltraCakeBakery]

@UltraCakeBakery I know how Svelte routes work. What I'm saying is that it's kinda crappy that on large projects we have 100s of index.svelte or route.svelte files, makes working with Svelte annoying. Like I said, would have been better if the file name was the same as the route name, with the exception being the root index.

Example

src
└── routes
    ├── foo
    │   ├── foo.ts

I don't see how it is crappy since you have the file directory. IDE's show it in the tab titles (enabled by default on most of them), cntrl+p allows you to suffix your search for a file with a /, in git you also see the file paths, stack traces show the path to the file for this exact reason..

Changing habbits is not fun, I get that, but you get used to this work flow very quickly.

[UltraCakeBakery]

It is also "kinda crappy that on large projects" you have "100s" of sub-route-specific components suffixed with _, and in general a inconsistent routes folder structure when you are dealing with index.svelte setups like src/routes/foo/index.svelte

[harrylaulau]

TLDR: After reading the above comments, I recommend:

1. keep the '__' prefix or any other prefix for these 'reserved' sveltekit-specific functional modules (layout, error, additional ones in the future)

2. Replace /page/index.svelte with /page/page.svelte

3. Use /page/<AnyComponentNameYouWant>.svelte for route specific components, such that in /page/page.svelte, one may include the component by import AnyComponentNameYouWant from "./AnyComponentNameYouWant.svelte" (No <> in the path name in import)

4. I think 'src/app' and 'src/routes' are both fine.

5. For special endpoints, instead of /[slug]/[slug].json.ts or /[slug]/index.json.ts, change to /[slug]/json.ts or /[slug]/[slug]/json.ts. Basically eliminating the route name on the endpoint and putting the return type of the endpoint as the filename instead. I am not sure if this is too off-topic (maybe it is) so please read my explanation below!

Explanation and description below:

1. Having a '__' or any other prefix distinguishes special reserved non-route functionalities of sveltekit, which could be easily distinguished from svelte files that represent routes.

2. Having too many 'index.js' seems to be a concern and I agree with the suggestions above that /page/page.svelte could be used instead of /page/index.svelte. While this sounds good to be true the only problem is we cannot have a /page/page route, and the only workaround would be /page/page/page.svelte which could be complicating (though /page/page/index.svelte doesn't look a lot better and this example is quite an edge case in my point of view)

3. For larger projects, which involve reusing components, a /lib directory is definitely helpful yet that's not to be removed as proposed by @Rich-Harris. Instead, what I think to be the takeaway is that in smaller projects, or even large projects, sometimes there are page-specific components (like splitting a huge page into subsections, that only appear in that route, or in that route and its child routes). For this kind of page arrangement, I think that it would be easier to have the sub-session components to be in the same directory as the page. Also maybe using <> to encapsulate the file name to make it obvious within the directory. Meaning /page/<Component1OfPage>.svelte and import Component1 from './Component1OfPage.svelte' in /page/page.svelte

4. Not much to comment on, English is my second language so in my point of view as long as the words' meaning doesn't deviate too much, and does not clash with other words, then it's pretty much similar for me. Still, I do agree src/app has a broader and covers more of the "use case" of files included than src/routes

5. I don't know if it is only me or also others, I find that having multiple file extensions index.json.ts is confusing. When I look for the file type, I first look at the end of the file, which is the file extension, I noticed its a .ts so it is an endpoint, then found out oh there is a second extension, sort of, so it is the endpoint of that type. It is fine when the number of files is small but when I look at a large list of files I start to puzzle. Instead, if the file is named as page/json.ts, I just look for a file named json then it's done! (This is how remix resource routes work and I think it seems to be better) Still, maybe this is more of my personal preference so thank you all for reading my comments!

[lukaszpolowczyk]

1. ok.
2. /page/page.svelte doesn't appeal to me. Using _page.svelte as a route (instead of treating the underscore as private) is my suggestion.
3. ok.
4. ok (rather indifferent to me, but with the new concept, app fits better).
5. i don`t have this problem rather.

[harrylaulau]

Thank you for replying me instead of only a emoji!

[lukaszpolowczyk]

I don't know if it was and probably stupid, but whatever:

• Layout error files, etc. should be with double underscore so that these special files stand out.
• Files without underscores should be treated as regular components.
• Index files as route.

AND (ATTENTION HERE!) - files with underscores as route!
That is, a little reversal of private files with route files.

Why? - Because by design, there should be more private files than route files - for each route, theoretically, there should be several private files.
So let's make underscores for files that are exposed, and treat all others as hidden.

(Plus index files also exposed, of course. Alternatively, let's make index files with underscores too...?)

Handicap (underline), let them have files that are fewer in number.
Mistakenly exposing a component disappears (that's the OP's goal).
etc.

[harrylaulau]

Just out of curious, may I ask how do you use the private files. For me I have just used it to define shared types and maybe shared helper functions between routes (client side) and endpoints (server side). Most of the time there isn't much so I only need one private file and named it _types.ts Another usage of private files is component specific to that route, which is solely for managing code in complex page. (Which recently I tried more nested routes with shared layout instead after learning remix)

[lukaszpolowczyk]

@harrylaulau Currently, I don't use private files at all, because it would be inconvenient.
I use only $lib/.
But often some components are only needed for one route, and then it makes sense. Now I have everything in $lib.
Anyway, the OP gave an example where $lib/ is no longer needed (I know that $lib/ stays, it's just not always needed and not for everything).

[harrylaulau]

@lukaszpolowczyk I am the same with you putting most of the things in $lib. I think what separates lib and routes is that the former is more of shared code while the latter are more route specific. Such that shared functions and components should live in lib while routes specific ones should live in routes. If you have time you might read my thoughts in the thread right above this one which further distinguishes route specific components and route specific functions. (But for my most recent project I actually created alias folders including $components $services etc which is also quite good imo. Still I think that this should live more up to personal preference or specific to project instead of making it a standard)

[mvllow]

I like the idea of routes being prefixed with an underscore. The one (sort of) issue that comes to mind is grouping for components that are meant for a single page. E.g. _some-page.svelte may consume a component called some-page-header.svelte but now those may not show next to each other in a file tree.

Another suggestion, without feeling strongly about it, would be to end the filename with .page.svelte, e.g. home.page.svelte. We see this convention with config files like tailwind.config.js.

[coryvirok]

Here's a polarizing but hopefully helpful addition to the convo:

Why not copy Next'js's new way of doing this?

Some benefits:

• next.js user onboarding to sveltekit would be more straightforward
• tooling that vendors are making for next could potentially interop with Kit in a more straightforward way
• Vercel (next.js creator and @Rich-Harris employer) would likely have an easier time porting next tooling to Kit.
• A standard could be created for frameworks that implement filesystem based routing so new frameworks could implement the standard and get all of the above benefits.

Network effects of standardization can be incredibly beneficial to Kit's ecosystem.

[dangelomedinag]

After reading the proposals/reactions, the following is appreciated:

1. Too many index.svelte files, dislikes most. (same with layout.svelte and error.svelte )
2. Many would like to continue to visually place {layout|error}.svelte files with a __ prefix.
3. Many justify the advantages that it would bring with respect to the current state of the router.
4. All opinions from the consumer's point of view. We understand that the change may be motivated by the fact that it will facilitate the internal management of the sveltekit team.

considering this and doing some tests:

1. Allowing optionally file names with index[.name].svelte could fix multiple {index|route|layout|error}.svelte.
   • OPTIONAL: the name can be index.svelte or index.docs.svlete. It will depend on how much effort you put into writing .docs to the files you want to easily locate.
   • the only use of [.name] is to avoid repeating the same name over and over again. It has no utility or logic for sveltekit.
   • advantage: the file starts with the {index|route|layout|error} keyword and ends with .svelte, is same as traditional index.svelte usage.
   • advantage: in case you take the time to write the files index.docs.svelte, layout.docs.svelte and error.docs.svelte, searching for 'docs' would show all 3 files in the path. (image at the end)
   • if you don't care about hundreds of {index|route|layout|error}.svelte files, you can skip the whole thing.
   • an advantage of writing route.svelte over index.svelte. is that it could search for 'route' and it will show you only pages in top results.
   • {index|route|layout|error}.svelte files cannot be imported into other files, so you never have to write the following:

<script>
  // you will never have to remember the name you typed for the file.
  import index from "./index.docs.svelte" 
</script>

2. If the {index|route}.svelte file is the only one that qualifies as 'page', I think you could dispense with the __ prefix without fearing that, due to ignorance, they might create 'pages' by mistake.
   • typing the '__layout.svelte' prefix, is very similar to typing 'layout.docs.svelte' and will help you differentiate it from other layout.svelte
3. if you change '/routes' to '/app', the 'route' keyword makes sense. 'index' will always be more universal. but 'route' has the advantage of being able to search only 'route' (page) files.

---

I leave some captures of everything.

• route[.name].svelte

• all named files. index.docs.svelte, layout.docs.svelte and error.docs.svelte.

• finally, zero files with names.

---

I have no idea if {index|route|layout|error}[.name].svlete, is an illegal filename in sveltekit. that would automatically eliminate this idea.

[lukaszpolowczyk]

It seems to me that when someone sees such a project folder, it will be ULTRA confusing.
People will be wondering why here it is with a name like folder, here without, here still different....
They will wonder if it makes a difference or not. They won't know what kind. What is it even for?
To me, very confusing for a new user.

[dangelomedinag]

precisely for that reason it would have to be optional yes or yes. When you create a new project with NPM you will only find {index|route}.svelte. It will be a decision of the development team. and for those who don't know the functionality or don't need to bypass the hundreds of 'index.svelte' simply don't have to do anything. The extra effort is for those who need it, at least they would have an option.

The explanation seems confusing, but at the end of the day, they would only be allowing me to "give an identifying name" to my files. index,route...

[lkj4]

@Rich-Harris any news? You got pretty quiet. Folks need to know how you gonna decide...

[dummdidumm]

There will be a new separate discussion with the learnings and thoughts since then. We'll let people know in here once it's out.

[igneosaur]

I think the following discussion is here for any one who's wondering. #5748