Closed nullxone closed 11 months ago
Latest commit: 470107d921e6a97b7db7e7d89ff8129d3267c6f7
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Thanks for the PR and sorry we somehow missed this PR. In any case, I don't think we want to go with this change. This is just going to cause a lot of problems and unnecessary work to current users.
I am closing the PR, if you want to further discuss this I'd suggesst opening a github issue first.
What this is: rename
auth.users
metadata in hasura toauthUsers
exactly in line with the other tables (example,auth.providers
metadata name isauthProviders
). But do not change the external API for backward compatibility.Why this:
users
is a very common model name, and is likely to cause namespace collisions; by namespacing theauth.users
table in such a manner, I hope to allow the package to be more easily used by more projects, even existing projects that are not being built from scratch.I'm using a fork with this modification in a hasura starter kit I'm putting together, thank you! I am interested in this package being the default jwt authentication option for building hasura applications.
Checklist
NA no new features
New features have new testsBreaking changes
No breaking changes to the API! All tests pass unmodified (except 1 that explicitly tests for the types).
Only the data layer is modified, the API still says things like
{ user: { ... } }
However, application developers who have set up relations in hasura will need to modify the target tablename.
For example:
profileUser: profiles -> users
becomesprofileUser: profile -> authUsers
Changing the relationships in such a manner in existing applications is the only change required to upgrade to this patch.
Documentation
If this patch makes sense for this project, we may need to communicate the breaking change for an upgrade path.