Make `src/components` part of SvelteKit's domain

At the moment, src/components (and the $components alias) is really just a convention, nothing more. I think it might be better to remove the alias from the default vite.config.js and into Kit itself for two reasons:

• we have the $app and $service-worker aliases pointing to things that Kit controls, and it feels a bit weird that $components is this whole other userland thing — the $ prefix feels like it should mean something that’s provided by Kit, but it’s not, and the distinction is slightly difficult to articulate (context: I’m going through the docs at the moment, and this stuck out)
• I’ve only talked about this obliquely, but I think it would be a huge win if SvelteKit was capable of building component libraries as well as apps — in other words, for there to be a svelte-kit package (name subject to 🐃 🪒 ) command that took the contents of your components folder and packaged it up as a library that could be consumed by other projects. (Every app has an internal component library of some kind; the distinction between an app with an internal component library and a component library whose app exists to showcase the components is merely one of focus.) For that to happen, the location of the component library needs to be known to SvelteKit, it can’t live in the Vite config.

At the same time, it’s common for both component libraries and apps to need JS helper modules that can be imported from anywhere in the app with ../../../../. A couple of times I’ve found myself adding new aliases like $utils or $common just because I feel weird putting those files in a directory called components.

So my proposal is two-fold:

• Change the name of the directory from src/components to src/lib, and the alias from $components to $lib
• Make it part of the Svelte config, i.e. config.kit.files.lib === 'src/lib'

If we did this, the Vite config would become empty, so we could arguably remove it from the project template altogether (but reference it in the documentation for people who need to customise stuff).

[antony]

As I got to grips with architecture in node, I noticed a pattern of people using lib for compiled js which would just be interpreted by node, and src for things like coffee/ts etc which would be compiled.

So I’m a little against the use of lib/$lib for that reason. I prefer src, perhaps just exposed as ~. $ could be reserved for svelte internals.

I should also mention that having a routes directory within a directory which is otherwise compiled and exposed feels a bit odd. I’d feel better about excluding a directory if routes lived inside something like src/_routes or src/.routes, but I also quite dislike both of those. Maybe there is better naming.

[Rich-Harris]

There is no src directory in any meaningful sense. There’s src/routes, which is the basis for the manifest passed to $app, src/setup which is used during SSR, src/service-worker which does what it says on the tin, and src/app.html which provides the page template. It just makes sense to collect all those bits of differently-treated source code in one place, and for that place to be called src. The only aberration is src/components.

How would this change interact with Vite features like import globs or plugins like dynamic import vars? This was a feature I wanted to use for a blog-like setup.

Completely orthogonal — I haven’t yet used those features personally, but they wouldn’t be affected by this proposal at all.

I noticed a pattern of people using lib for compiled js which would just be interpreted by node, and src for things like coffee/ts etc which would be compiled. So I’m a little against the use of lib/$lib for that reason

The thought did occur to me. It could be anything — package? modules? exports? — but lib was the least worst thing I could think of. I don’t know if we need to be constrained by Node ecosystem idiosyncracies — we’re talking about formalising the concept of an internal library, and lib is a fairly commonly understood abbreviation for that word. But I’m certainly open to alternatives.