search

lucia-auth / lucia

Authentication, simple and clean
https://lucia-auth.com
MIT License
8.32k stars 447 forks source link

Split the monorepo into multiple repositories #1377

Open pilcrowOnPaper opened 5 months ago

pilcrowOnPaper commented 5 months ago

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 commented 5 months ago

We would separate the packages into:

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

LinusOP commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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:

Sothatsit commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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

pilcrowOnPaper commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

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

....

eric-burel commented 5 months ago

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:

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.