How should we upgrade supabase?

what is the recommended process for upgrading packages handed to us by redwoodjs

specifically, in my case, Supabase – it’s 1.13.2 in my repo and 1.22.6 in their github repo

they aren’t even in the package.lock file - so I don’t know how to see if I am up to date or not…


Ah, this is a good question and in general something that’s not always clear. For Auth providers and setup integrations built-in to Redwood, do know that we are often upgrading and testing requirements against the latest available versions. The current version of Redwood (v0.36) uses "@supabase/supabase-js": "1.21.1" And the upcoming release (v0.37) will use the latest "@supabase/supabase-js": "1.22.6",

In general, you can try upgrading your project to the latest version of a dependency. If things break, revert the change and then open a GitHub Issue as we’ll want to know an internal update is required to support the latest.

More often that not, what is likely to happen is that you’ll try to upgrade Redwood and discover a dependency you have is outdated and causing an issue. That’s when you’ll realize you need to upgrade.

Lastly, did you mean to write yarn.lock instead of package.lock (since the latter is only created if you’re using npm package manager)?

1 Like

So, as a general rule of thumb, the latest version of RedwoodJS will support the latest version of its dependencies?

That’s what we are aiming for!

The challenge will be major version dependency upgrades that have breaking changes. Once we hit Redwood v1, we will hold breaking changes until Redwood has major version upgrades, eg v2.

1 Like

Yes I did mean yarn.lock - but package.lock was there and kept regularly up to date - even tho’ I use yarn – confusing and a good reason to pitch and toss and rebuild node_modules.

Auto upgrade of deps is great, and another thing I just love about RW.

I’ve not seen any mention of Mutating Cells - did I miss it?

1 Like