fix: namespace storage key

[kangmingtay]

What kind of change does this PR introduce?

• Fixes Namespace cookie / localstorage auth-js#361
• See gotrue-js PR for reference (fix: allow custom storage key in localstorage auth-js#303)

[sannajammeh]

Great work!

However, this could make the storage key a guessing game as its being inferred and as such might introduce a breaking change for unaware users (pulling from localStorage manually with the default key currently used).
I'd recommend leaving it up to the user to define it in createClient() and fall back to the default one otherwise.

createClient(URL, KEY, {
   // Options
   storageKey: "myproject-sb" // or authStorageKey: "..."
})

[kangmingtay]

hey @sannajammeh, it wouldn't be a guessing game because the developer would know what the storage key is based on the project-ref from the supabase url provider when the client is initialised

[sannajammeh]

Hi @kangmingtay

My reasoning is it will unknowingly create a guessing game. I would know because I've read this PR and read through the changelogs, but someone for instance blindly doing a pnpm update would not.

Let's say Release x.1 contains the current behavior of a single key. I pull from local-storage manually for various reasons. I update the library to x.2 and all of a sudden the app breaks due to the local-storage key changing (even though I'm only using a single instance of SB).

If I haven't read the changelogs I wouldn't know the real reason my app is breaking is actually that the local-storage key has changed.

The cookie options allows for custom key's decided on by the developer. Therefore my take on it is the developer running multiple instances should be the one responsible for managing conflicts between them (same how the current sdk uses cookie name). Allow a custom storageKey configuration option and fallback to the default key to not break backward compatibility. Ultimately more control for the library consumer.

This is obviously just a suggestion and the example I'm providing is an edge case. Either solution is ultimately positive!

[pixtron]

To me that PR looks good. But - as @sannajammeh says - it is a breaking change. Strictly following semver, this PR would require the release of supabase-js v2.0.0 (breaking change -> new major).

Until v2.0.0 supabase/auth-js#361 could be partially fixed by letting consumers pass in a custom storageKey to createClient and pass it down to gotrue-js. Basically the same as @kangmingtay already did in supabase/auth-js/pull/303. So consumers that have multiple clients on the same domain, can set unique keys for them.

This current PR could always be added in next major and serve as a default, when there is no storageKey set in the createClient options. I'd really like to see namespaced storage keys!

Also an update to a version containing this PR would log out every user session as soon as users get the new code (new key !== old key). And there would eventually also be garbage sessions left in storage under the old key.
This could be solved with a migration. 1. reading session from the old key, 2. if the session is a session for the current authUrl store it under the new key and remove the old key. Although such a migration would be probably a bit over engineered.

[alaister]

LGTM! 🔥

[kangmingtay]

Hey @pixtron and @sannajammeh, thanks for the feedback! I've made the necessary changes so you'll be able to pass in a custom storage key in the next major version release.