Make src/components part of SvelteKit's domain

[Rich-Harris]

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).

[Conduitry]

Is this materially different from having an import from '~/whatever/...' alias where ~ points to some known root (or src/) of your project?

Separately, I recall reading that src/node_modules/ stuff was a no-go in Snowpack - is it also in Vite?

[Rich-Harris]

Not different at all, no — it's exactly that.

is it also in Vite

yes, sadly. Though in this case I think I'm okay with it since we need the known location for svelte-kit package

[Conduitry]

Are you attached to the $lib syntax as opposed to the ~/ syntax? The latter seems to have been popular during The Bundler Age, and it seems to be a weaker opinion than the $lib thing, which feels like a slightly weird thing to bake it.

If one of the reasons for the $lib syntax over the ~/ syntax is that only one of them is easily possible in Vite, then I will take my seat. It sounds, though, that the important reason for you is the svelte-kit package thing. How is this, exactly? Presumably with $lib (where you are now allowed to have JS/TS files as well as components), the package command would do some sort of traversal looking for .svelte files. Why not just do this to all of src/ and skip src/routes/?

I apologize if it sounds like I'm being difficult. I'm just not yet convinced that $lib isn't an unnecessary opinion.

[Rich-Harris]

Because you definitely don't want stuff in src/routes to be published as a component library! If you're publishing a package, the package root needs to be specific to that purpose (i.e. src/foo rather than src), and ~/ variously means 'project root' or 'src'

[benmccann]

lib probably is a better default name than components. It's not quite clear to me that there's reason to bake it in yet

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 water_buffalo razor ) command that took the contents of your components folder and packaged it up as a library that could be consumed by other projects

I would think if you're building a component, you'd want to just put your source in src instead of src/lib

you definitely don't want stuff in src/routes to be published as a component library

Why would you even have src/routes if you're building a component?

[Conduitry]

Well I did specifically mention skipping routes in my comment.

edit: Oh. Apparently I didn't entirely read Rich's comment.

If you're publishing a package, the package root needs to be specific to that purpose

Hmmmmmmm. I guess yeah it would be convenient to be able to just point to a place for consuming a project. (I was only thinking about what svelte-kit package would do.) .npmignore is a thing, but I don't know that that's worth it.

[GrygrFlzr]

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.

[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.

[benmccann]

having a routes directory within a directory which is otherwise compiled and exposed feels a bit odd

I'm not sure I understand. It sounds like you're saying the routes directory is not compiled, but I think that it is

[antony]

I'm not sure I understand. It sounds like you're saying the routes directory is not compiled, but I think that it is

Sorry what I meant was that this routes directory was treated differently from its containing directory. I feel like that's a bit unexpected.

[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.