Un-Deprecate `config.kit.files.*`

[Squidgical]

Describe the problem

#14151 calls for this config option to be deprecated. Personally I've made use of this on the majority of Kit projects I've worked on, as I dislike the default file structure.

It feels like deprecating this is unnecessary and forces devs to comply to a certain file structure.

It adds complexity and inconsistency for no good reason.

While it's definitely true that it adds complexity, I'd argue that "allow developers to structure their project how they see fit for their use case" is a good reason, even if "how they see fit" is an aesthetic decision rather than a practical one. I'd also argue that the "complexity" doesn't need to be anything more that a member access in place of a hard-coded string (if the configured path doesn't work, that's the dev's fault, not the framework's).

The inconsistency is another part of this "how they see fit". I think for most Kit devs, if they came across the example I gave above in a project, they'd be able to quickly figure it out; Svelte users are a smart bunch. If you're making a project with the expectation of many newcomers arriving and contributing, that's gonna factor in to your "how they see fit", so what is enforced by the deprecation is already happening by convention in most cases where the argument against inconsistency applies.

Having the structure of your app match what's in the docs is an unambiguously good thing.

This is true. What is also true is that anyone using config.kit.files.* has a good enough understanding of Kit's file structure to be able to translate between the default structure and their own near-effortlessly. Allowing developers to decide whether they value matching the docs or their own file structure is, I would argue, an unambiguously better thing.

This was always true (the whole point of a framework is that you're able to easily move between codebases), but it's even more true in a world of coding assistants.

(emphasis mine)

Thing is, over time I've changed how I use config.kit.files.* through multiple different setups over the years, and its been very easy to revisit these projects after a long time away as the content of each of these folders is quite self explanatory, and the few named files (hooks, *.html) are hard to reasonably name in a way that isn't obvious as to what they are. In the worst case, I take a glance at config.kit.files.*, and a few seconds later I'm up to speed.

---

Of course, this all is my own subjective experience. I'm not suggesting that this is true for everyone (most devs admittedly don't use config.kit.files.*), however I would be surprised if this isn't at least somewhat representative of other users of this config option.

An Example

The setup I like to use currently looks like this.

Kit config

/** @type {import('@sveltejs/kit').Config} */
const config = {
  preprocess: vitePreprocess(),
  kit: {
    adapter: adapter(),
    files: {
      appTemplate: 'index.html',
      errorTemplate: 'error.html',
      assets: 'assets',
      lib: 'lib',
      params: 'params',
      routes: 'routes',
      hooks: {
        client: 'hooks/client.ts',
        server: 'hooks/server.ts',
        universal: 'hooks/shared.ts',
      },
    },
    alias: { // nb: I don't use `$lib` in imports
      '$server/*': './lib/server',
      '$shared/*': './lib/shared',
      '$res://*': './lib/resources',
    },
  },
}

VSCode settings

{
  "explorer.fileNesting.patterns": {
    "svelte.config.js": "vite.config.ts, vercel.json, tsconfig.json, .*rc, .*ignore", // all configs
    "package.json": "pnpm-lock.yaml", // fast things
    "index.html": "error.html", // meh, its non-bad enough I haven't deleted it
    "+layout*.svelte": "+layout.ts, +layout.server.ts", // client/server loads grouped
    "+page*.svelte": "+page.ts, +page.server.ts"
  },
}

File structure

- assets/
- hooks/
  - client.ts
  - server.ts
  - shared.ts
- lib/
  - server/
  - shared/
  - resources/
- params/
- routes/
- index.html
  - error.html
- package.json
- svelte.config.js # vscode file nesting
  - tsconfig.json
  - vite.config.ts
  - ...vercel, git, prettier, etc

Describe the proposed solution

- * @deprecated

and don't remove the functionality.

Alternatives considered

Afaik, if this config option goes it will be impossible to change the structure of a SvelteKit project from what the framework dictates, meaning the only alternative is to maintain a fork. That would kinda suck.

Importance

would make my life easier

Additional Information

I understand this config option adds complexity, but without it at some point or another there's got to be some const routes = "src/routes", is it truly too much to have some const routes = config.kit.files.routes?

[benmccann]

I recognize that we've made a somewhat opinionated stance here, but also feel that it's a place where we're better off having opinions than letting everything be configurable. All the maintainers feel pretty strongly that we're better off with convention over configuration here and none of us are quite sure why we even had these options to begin with which predate our even using Vite. I don't think any new information has been introduced here to cause a reconsideration

[nosovk]

@Squidgical you are not alone, check #14152 (comment)
We are ok with folder structure, but we want to host multiple apps inside one repo, by choosing which route folder to use.

[ebolyen]

I do think switching the route folder is very convenient, we use this feature to slightly vary the same application between different deployment approaches: one is for a SPA with a service worker which is the "real" server, and the other is a CLI tool where the service worker is swapped out for a simple file server. I'm sure there's other ways for us to accomplish this, but path.routes seemed like the most obvious escape hatch to us.

[nosovk]

You can describe your experience in discussion about that feature - #14240
Put your use case on the table :)