I've been using the new Basejump package since its release. First, I wanted to say that it's great work and I appreciate you built this to assess Supabase's needs for a native(ish) organization system. Tho I think, dbdev (and the project being a package) greatly limits the ability of it to be truly useful.
Second, this makes local development impossible if you're not connected to the internet.
Third, is that the project provides an awesome starter set of functions and tables for a team system but makes it unnecessarily complex to extend it. I have to dig into the Basejump SQL file on GitHub, search for the relevant sections and copy-paste that part into a new migration in my project. This is way less productive than just a simple copy-paste when integrating Basejump.
A few examples that came up where I needed to extend:
Use the generated usernames as slugs throughout a site. Then I found out that it is not guaranteed to be unique. Or let Basejump use the usernames set by users or my app on sign-up.
Personal accounts to also use the slug column.
Add new application-wide roles plus RLS.
Access Basejump account IDs on auth.users or in a custom public.profiles
Adding a trigger function to the same event targeting the same table as Basejump (ex.: run_new_user_setup() on auth.users) gets very confusing because of how postgres handles the function execution order. Especially if I want to have access to the Basejump account_id in my function. It'd be way simpler if we could just extend the already existing Basejump function.
So, I recommend making the core functionality copy-pastable and extensible by default, just as the UI components (as the shadcn/ui components). The command @usebasejump/cli@latest init should create a migration file (or ideally multiple files by feature) with the chosen functionality, instead of a dbdev HTTP call.
I've been using the new Basejump package since its release. First, I wanted to say that it's great work and I appreciate you built this to assess Supabase's needs for a native(ish) organization system. Tho I think, dbdev (and the project being a package) greatly limits the ability of it to be truly useful.
First, the maintainers are already unable to publish the first big update, due to an issue with dbdev.
Second, this makes local development impossible if you're not connected to the internet.
Third, is that the project provides an awesome starter set of functions and tables for a team system but makes it unnecessarily complex to extend it. I have to dig into the Basejump SQL file on GitHub, search for the relevant sections and copy-paste that part into a new migration in my project. This is way less productive than just a simple copy-paste when integrating Basejump.
A few examples that came up where I needed to extend:
auth.users
or in a custom public.profilesrun_new_user_setup()
onauth.users
) gets very confusing because of how postgres handles the function execution order. Especially if I want to have access to the Basejumpaccount_id
in my function. It'd be way simpler if we could just extend the already existing Basejump function.So, I recommend making the core functionality copy-pastable and extensible by default, just as the UI components (as the shadcn/ui components). The command
@usebasejump/cli@latest init
should create a migration file (or ideally multiple files by feature) with the chosen functionality, instead of a dbdev HTTP call.