Make supabase-js a monorepo

[bnjmnt4n]

Chore

Describe the chore

Currently, there are various repos for the various JS clients: gotrue-js, postgrest-js, realtime-js, storage-js, and supabase-js which wraps them all. This makes it harder to track issues across the various separate repositories. Issues which are fixed in one of the constituent repositories also require an explicit version bump in the supabase-js repository, which adds another layer of indirection for new users.

Given that most Supabase users tend to just use the main supabase-js client which is also highlighted in the docs, I'd propose converting supabase-js into a monorepo which contains all the separate clients. Additionally, this might also ease the transition into using a more tree-shaking friendly approach as planned for 2.0 releases (#170).

[soedirgo]

Super late reply: I suppose one blocker is this makes versioning and publishing difficult - we use semantic versioning + conventional commits + semantic-release for most repos.

Issues which are fixed in one of the constituent repositories also require an explicit version bump in the supabase-js repository

This is actually not needed - e.g. for a bug fix in postgrest-js npm update @supabase/postgrest-js should be enough. (We do bump the version in supabase-js anyway, though it's kinda redundant.)

Other concerns are valid - difficulty to track issues, tree-shaking. The latter probably needs to wait until there's a proposal on how to go about it - I'm personally not familiar with tree-shaking and how monorepos benefit from it.

[JoelLau]

@soedirgo , just thought you might want to know that nx workspaces (monorepo tool) provides way to publish npm libraries

[ruggi99]

+1 on converting to a monorepo.

Many months ago I was against monorepos in general. I didn't see any improves in workflow and versioning was scaring to me.

But I started a project myself with lerna and later changed opinion.

In my little experience I can tell that monorepos are powerful and versioning is wonderful. Not all projects are eligible to be developed in a monorepo but this project it is.

Reasons:
In JS ecosystem is difficult to update indirect dependencies, we all know. So in supabase-js all other repos are direct dependencies and so indirect dependencies in all projects using supabase-js. But supabase-js dependencies are specified with a range and so not always updated correctly. And tracking issues and updates are difficult as mentioned above.
Versioning might be overwhelmed and unnecessary sometimes but helps a lot with updating indirect dependencies.
Overall I think monorepo could be considered.