feat: add a kit.files.src option

[Rich-Harris]

Implements the idea in #14077 (comment). This adds a kit.files.src option, defaulting to src, which specifies where your source code lives. lib, routes etc are now relative to that by default, so if you have this...

// svelte.config.js
export default {
  kit: {
    files: {
      src: 'source'
    }
  }
};

...your $lib alias will point to source/lib. No need to set up separate values for everything inside your source directory.

The real draw of this is that we can use the src option for other things, including #14077 (though that's not implemented yet — TODO).

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[benmccann]

I personally don't love this. If someone changes the location of the src folder it makes it harder for everyone using that project. I like the convention over configuration stance we've had and would rather include everything under src than allow src to be something else

[Conduitry]

We already let people configure just about everything in src, though - https://svelte.dev/docs/kit/configuration#files - Letting people move all of those at once doesn't bring any additional variation between projects. It maybe even could reduce it if in a later version we could remove some of those and require they be in the same relative places to one another.

[Rich-Harris]

Exactly. I for one would love to deprecate all the non-top-level options. I'd be astonished if anyone is actually using them, but if anyone is they're probably having to set them all, redundantly. I don't think anything is really gained by making that stuff configurable (though the top-level option is probably an escape hatch worth having), but stuff is definitely lost — imagine you're coming to a SvelteKit codebase and someone has renamed everything for shits and giggles.

Especially in a world of coding assistants, having things be consistent between projects is valuable. We're saying the same thing, of course, I'm just arguing (alongside @Conduitry) that this additional piece of configuration advances a have-less-configuration agenda.

Once I get the tests passing I'll open a 'deprecate all the others' issue so people can weigh in

[changeset-bot]

🦋 Changeset detected

Latest commit: c7afab9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benmccann]

I'm all for deprecating the other options! But I still don't understand why this one is needed. It doesn't seem to solve the issue in #14077 (comment) at all, which is that they want to put some code outside the routes directory. I don't think they want their code in source/routes instead of src/routes. They want their code in src/remote-functions or something along those lines

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-14144-svelte.vercel.app/

[Rich-Harris]

It will fix #14077 because instead of crawling [kit.files.lib, kit.files.routes] for .remote.ts files we can crawl kit.files.src

[benmccann]

Can't we crawl src without making it configurable though?

[Rich-Harris]

If someone has config like this

export default {
  kit: {
    files: {
      lib: 'source/lib',
      routes: 'source/routes'
      // ...
    }
  }
};

....then crawling a hardcoded 'src' won't help them. We need to crawl kit.files.src and, for backwards compatibility, the existing directories

[benmccann]

Right, we have to crawl the existing directories for backwards compatibility. No argument there. Still not sure why src needs to be configurable though. Or at least if we add it, can we deprecate it along with all the others? 😆