Replies: 1 comment
-
Asked a friend who knows Vue and it's ecosystem better because I wondered if next or nuxt might have something like this and apparently NuxtJS Layers are this exact feature I'm describing! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In enormously huge applications a recurring issue I always find is that modules are imported left and right form a big incomprehensible ball of yarn that you can't untangle.
One solution I see is splitting apps off to libraries with a well defined surface area. In a pnpm monorepo you're forced to declare the package dependencies, leaving no question on what's used and where, and the package.json exports object clearly defines that surface users can see.
These smaller, well defined application chunks can then be owned by different teams.
In Angular apps this is doable because routing is entirely client side and everything is declared using typescript. I could export an entire subtree of an app and reuse it in another app.
The thing is, I've not seen this kind of architecture in real life yet, so I can't point to something and say this is good. But if I'd bring SvelteKit to my team I'd want to architect my app like this to not make the same mistake with SvelteKit that happened with the Angular app.
If sveltekit would have the ability to package an entire application - together with the application tree the routes folder defines - and then allow me to inject said application into a route of another application so it can compile everything together, then this would be possible.
Currently
svelte-package
is used to export only thelibs
folder, leaving theroutes
folder alone, as the documentation suggest, it could be used for demo or documentation sites on it's own.Just to clarify I'm not talking about microfrontends, this would entirely be compile time. This is only about the ability to split one application into multiple packaging, while retaining the ability to use the filesystem router in the libraries. Currently I only have to tools to create libraries out of regular svelte components, but not entire sveltekit routes.
Depending on how much work can a prepackaged sub-app can do ahead of time, the cache layers between these packages (Like a package registry, or nx/turbo style computational caching) could speed up builds in these huge applications a lot.
Beta Was this translation helpful? Give feedback.
All reactions