Split the monorepo into multiple repositories

[pilcrowOnPaper]

Working with multiple packages in a single repository has been a pain in the ass. It gets worse when you have to maintain multiple versions and preleases. This repository uses a custom solution called Auri, and while it could be better, Changesets haven't seemed to find a clean solution either.

At this point, I'd rather a repository for each packages, e.g. lucia-auth/lucia, lucia-auth/adapter-sqlite. The lucia-auth organization doesn't have a lot of repositories so it wouldn't make be hard to organize/find packages either.

[pilcrowOnPaper]

We would separate the packages into:

• lucia-auth/lucia
• lucia-auth/adapter-test
• lucia-auth/adapter-sqlite
• lucia-auth/adapter-mysql
• lucia-auth/adapter-postgresql
• lucia-auth/adapter-drizzle
• lucia-auth/adapter-mongodb

I'm not sure if the docs should be in lucia-auth/lucia repository or in its own lucia-auth/docs repository.

[LinusOP]

My opinion is that if you feel it would make developing and maintaining Lucia easier then go for it.

There's not an awful lot of contributors and considering that it still won't be that many repos I'm sure we'll be able to work with it. It's more important that it works for you considering you still push the overwhelming majority of the code.

[Sothatsit]

If this makes maintenance easier, I think it would be a positive change 👍

I have found that having docs in the same repository is easier for my own projects. A separate repository makes it more cumbersome to coordinate updates to both the library and the docs at once. In my experience I have commonly wanted to update both at once.

[ahmedrowaihi]

my suggestion
Avoid doing over splitting adapters, that would be a lot exhaustive to maintain
Would rather keep them in a single package, and call it “adapters”
it could be tree shakable if exports were explicitly stated

I see this as a good mono:

• apps
  • docs
• packages
  • core (lucia-auth/lucia)
  • adapters (lucia-auth/adapter)

[Sothatsit]

Additionally, would switching to a repository-per-package make it difficult for people to submit new adapters? They would no longer be able to just make a PR.

[gjtiquia]

Curious to know, what exactly are the pain points you have experienced when maintaining all these packages?

Also would like to know, what made you want to use a custom solution Auri, that you built, instead of other existing solutions such as Changesets?

Seems the trend now is going towards monorepos, with tools such as Turborepo and Nx, DX-wise what are the benefits of having multiple repositories?

Don't get me wrong tho, if multiple repositories are in-fact much easier to maintain I'm all for it!

Just want to learn what are the specific painpoints with monorepos and if there are possibly existing solutions to help. Because monorepos do have a lot of advantages over multiple repos, for example like @Sothatsit mentioned consolidated PRs, and also cross-referencing packages during development.

If we indeed decide on going for multiple repos we'd need a good contributing guide on how to work with all these repos.

[pilcrowOnPaper]

@gjtiquia Ideally I'd like to have a branch for each major version, but that's only realistic if each adapters/integration major versions are tied to a single lucia major version. Tbh, I feel like this repository doesn't gain much from being a monorepo aside from having everything in a single place. Tooling in general is much easier to build when you don't have to worry about multiple packages as well.

[pilcrowOnPaper]

As for Auri, it was mostly because I just wanted to build something that works with GitHub actions. It has started to fall apart with v3, but it's done a pretty good job most things considered lol.

[pilcrowOnPaper]

@Sothatsit I'm not worried about that too much since I try to dissuade people from adding new packages anyway

[pilcrowOnPaper]

Ultimately, for me personally, it's easier to organize and work on tooling when each repository is for a single package. There are benefits to monorepos but I don't think Lucia and its related packages are complex enough to see the benefits of the architecture, especially when considering the tooling required to get it right.

I don't want to rush this though so I do want to think about this for a while

[SirMishaa]

For those who don't know, the advantages of a mono-repository can be found here : https://monorepo.tools/
This is a very good site with resources and easy-to-understand illustrations.

It looks like the whole codebase is in Typescript, and although tooling currently seems to be the biggest problem, I'd consider spending some time on it to find a suitable tool like Nx for example, rather than completely changing the repository's architecture.

In my experience, I also had a bit of a hard time getting to grips with the tooling at first, but once I did, it was still very practical, and I think the long-term advantage is largely in favor of mono-repository.

How about trying to migrate to another tool, and if that doesn't work, splitting between multiple repositories ?
Sometimes, just having the right tool can solve a lot of problems.

[ahmedrowaihi]

This project is already a monorepo tho, it's spliced into

• lucia - adapters
  idk what benefits pilcrow to over split the adapters, they are mostly looks same sharing one shared adapter interface
  it even better by its form now as if he adds a new feature to the adapter interface, he wouldn't be forgetting some spliced away adapter

For those who don't know, the advantages of a mono-repository can be found here : https://monorepo.tools/

....

[eric-burel]

If that's of any help, a few years ago I moved the Vulcan framework code base (an abstraction over Meteor that was popular some years ago) to a monorepo of packages. At this time, we lacked examples of mature monorepos with:

• fullstack packages with multiple entrypoints
• typescript, with source maps in the exported packages
• a fast build system to generate the packages (build systems target apps in priority and the documentation for building packages is often terser)

The code is open source and lives there: https://github.com/VulcanJS/vulcan-npm
It's now a legacy project but perhaps you'll find a few tips there. In addition to packages, it includes demonstration apps (much faster to code with than having a separate app with Yalc, symlinks are not always working as expected) and the documentation.

It's a "realistic" setup in the sense that I coded this mostly on my own, compared to say Next.js repo which has an awesome setup but is the results of the work of many contributors.