[RFC] Convert SDK polyrepo setup into a monorepo

[david-chalk]

NOTE: this issue tracks the discussion around the decision to even do this. This is not the implementation issue.

Situation

FusionAuth currently has 3 web SDKs: one for React, one for Vue, and one for Angular. Each SDK lives in a unique Git repository. Given that all 3 SDKs solve the same exact problems (just with different implementations), there is a huge overlap of functionality, dependencies, and process (like tests, linting, etc).

Challenge

Currently, because the 3 SDKs all live in separate repositories, we have to duplicate the functionality and processes that they share. We also have to keep up with updating shared dependecies among all the projects. All of this has a negative effect on developer productivity and also makes it hard to make all 3 SDKs be 100% cohesive.

Question

How can we make managing and sharing code easier among the 3 FusionAuth web SDKs?

Answer

Let's create a monorepo.

What's a monorepo?

A monorepo is a collection of multiple different apps and/or packages in a single codebase.

Why use a monorepo?

Using a monorepo will increase developer productivity via a number of avenues:

Manage multiple projects in a single repository

Having all the SDKs in a single repository can simplify project management. Considering all of the SDKs provide the same functionality, an update or fix for one has a decent chance of needing to apply to the rest of them. Given this fairly tight coupling, having one place to keep track of issues could be beneficial.

It can also be useful to have one URL to hand out and say "here's the FusionAuth web SDKs". There's also deduplication of documentation that can make maintenance easier. General documentation (like any notes on server side requirements or just general explanations) can live in the root README file. The documentation for implementation differences can live separate README files for each SDK.

Code visibility

Anyone working on the web SDKs only needs to checkout one repository and then has access to look around at all of the source code for the SDKs.

Easier dependency management

Right now, if we want to update or add shared dependencies, we have to go to each individual repository and update the dependencies. With a monorepo, we can easily ensure all of the SDKs use the same exact shared depenecies, and there will only be one place where a developer must do the work.

Easier code sharing

Currently we duplicate any shared functionality among the SDKs. With a monorepo, we can extract shared code and make it available to each SDK. We can share testing setups, business logic, styling, etc. Which means changes to that shared code is immediately updated for each SDK.

An alternative is to make separate packages for the shared code. This is a much more time-intensive and process-heavy approach, however.

Ok, I'm interested, how would it be implemented?

Vercel makes a free product called TurboRepo which is a framework for creating a monorepo. It handles all work around managing dependencies and tasks. It's popular and very well supported.

How will deployments be affected?

If desired, we can use a similar deployment strategy to the current one. We'd just need to make some decisions around whether the repo "release" version is arbitrary to the individual SDK package versions or not.

What's the lift? 💪

It's tough to give a super accurate estimate for this one but because the SDK codebases are still relatively small and simple, there isn't much complexity to deal with. This should help make the process fairly straightforward.

Estimate: 2 developers 3-4 days

[david-chalk]

Requesting comments and thoughts from @mooreds.

[michaelyons]

Requesting comments and thoughts from @lyleschemmerling

[lyleschemmerling]

I think that a mono-repo makes a lot of sense for what we are trying to do with the sdks and even their example repositories, and there is absolutely a case to be made for pulling common functionality into a shared lib amongst the existing sdks and any additional ones that we want to add.

I think that the deciding factor for something like turbo-repo needs to be ease-of-use and overhead for developers in the repository, which could be FusionAuth affiliated developers making updates or other developers/customers coming in who want to kick the tires on the libraries and possibly even contribute. We can't ask people to learn a new technology just to see if our auth buttons work for their react app.

We don't really have complicated build pipelines or long-running test suites to worry about so the benefit from that standpoint is minimal, but if turbo-repo keeps us organized I suppose it is okay, especially if it makes pulling in shared functionality easier.

[david-chalk]

@lyleschemmerling

Agreed. TurboRepo could be more than we need. We've had success with Yarn Workspaces in the past. Maybe we start there and change if ever deem it necessary?

[lyleschemmerling]

That makes sense. Let's get the SDKs into a state that we are happy with, and then we look at the commonalities and determine how best to fit them into a monorepo.

[JakeLo123]

This is done! Here's the repo