Structuring larger sveltekit apps - best practices

[xpluscal]

I'd love to know what the community thinks in terms of structuring complex / larger svelte apps.
Especially when it comes to modularity around certain features and organizing around the routes / lib folder.
So basically co-locating routes and functionality vs separating them.

E.g. consider the following two scenarios:

Scenario 1:

── lib
│   ├── modules
│   │   ├── core
│   |   |   ├── components
│   |   |   ├── models
│   |   |   ├── types
│   │   ├── moduleA
│   |   |   ├── components
│   |   |   ├── models
│   |   |   ├── types
│   │   ├── moduleB
│   │   |   ├── ...
├── routes
│   ├── moduleA
│   │   ├── +page.server.ts
│   │   ├── +page.svelte
│   ├── moduleB
│   │   ├── +page.server.ts
│   │   ├── +page.svelte

Scenario 2:

── lib
│   ├── components/
│   ├── models/
│   ├── types/
├── routes
│   ├── moduleA
│   │   ├── components/
│   │   ├── models/
│   │   ├── types/
│   │   ├── +page.server.ts
│   │   ├── +page.svelte
│   ├── moduleB
│   │   ├── components/
│   │   ├── models/
│   │   ├── types/
│   │   ├── +page.server.ts
│   │   ├── +page.svelte

What are your thoughts around the two approaches
(1 is more using the library for everything and routes purely for routes and endpoints and 2 is more fully encapsulating / co-locating all functionality inside the routes themselves and only keep core functionality inside lib)

Feedback much appreciated.
I've seen more colocating in the svelte demo app, not sure if this is the direction we're heading here as the suggested approach.
@Rich-Harris

[cdcarson]

I'm doing approach 2. Put as much logic as you can as close as you can to the page in the route tree. Only things that are obviously utilities and/or will obviously apply to more than one "top-level route branch" go in $lib.

This leverages the merged page data types that are generated by SvelteKit for each node in routes. As long as you have an ORM (in my case, Prisma) or a similar data layer this means you really don't have to hand-write lots of types or abstract much away from the page/route at hand.

It took me a while to get used to this -- i.e. I was used to writing services and models and so on to "uncouple" things like data and presentation, and my instinct was to put those things in $lib, away from the route "controllers". But I've found that to be unnecessary.