Feat: MapClaims Key Type-Safety

[YlanzinhoY]

I introduced this feature to improve type safety, preventing us from mistyping the string in MapClaims, thus providing a slightly better experience. Of course, with 5 minutes of research you already know what MapClaims expects, but with this safety feature, simply pressing ctrl+space shows developers the types it expects.

Before

After

---

I can blend the new way with the old way and it works.

---

ctrl+space

[oxisto]

That is a very interesting idea. I wonder how backwards-compatible this is, since we do not want to break existing code in the v5 branch and it does modify public API functions. Need to play around with that first. In any case this could be interesting for a v6, for which I want to start the development soon.

[oxisto]

I had another look at this and I really like the concept.

@mfridman what are your thoughts about merging this into v5? It should not really break anything except in case where people are doing really really really weird things such as manually casting a map[string]any into MapClaims (or vice-versa).

I am not really sure about the ClaimsType name, should probably be clearer that it only relates to MapClaims.

[YlanzinhoY]

I had another look at this and I really like the concept.

@mfridman what are your thoughts about merging this into v5? It should not really break anything except in case where people are doing really really really weird things such as manually casting a map[string]any into MapClaims (or vice-versa).

I am not really sure about the ClaimsType name, should probably be clearer that it only relates to MapClaims.

Which name do you think is best? I can make a change if you want.

[oxisto]

ClaimsType

Maybe MapClaimsType

[mfridman]

I had another look at this and I really like the concept.

@mfridman what are your thoughts about merging this into v5? It should not really break anything except in case where people are doing really really really weird things such as manually casting a map[string]any into MapClaims (or vice-versa).

I am not really sure about the ClaimsType name, should probably be clearer that it only relates to MapClaims.

I don't think we can take this chance, there are too many dependents. And from a maintainer's perspective, I am always biased towards extremely strong backwards compatibility.

[oxisto]

I had another look at this and I really like the concept.
@mfridman what are your thoughts about merging this into v5? It should not really break anything except in case where people are doing really really really weird things such as manually casting a map[string]any into MapClaims (or vice-versa).
I am not really sure about the ClaimsType name, should probably be clearer that it only relates to MapClaims.

I don't think we can take this chance, there are too many dependents. And from a maintainer's perspective, I am always biased towards extremely strong backwards compatibility.

Understandable. Since "main" is now the to-be-v6, we can still merge it, after we agree on a name for key-type.

[oxisto]

I settled on MapClaimsKey for the type name. @mfridman your turn

[mfridman]

Understandable. Since "main" is now the to-be-v6, we can still merge it, after we agree on a name for key-type.

Probably outside the scope of this PR, maybe we can chat on Slack/email.

But wdyt about keeping main as v5 and having a long-lived v6.0.0-rc.1 (or v6.0.0-beta.1) branch with all the breaking changes? Keep in mind we'll need to change the go.mod, so /v5 users shouldn't be affected and we can continue to add bug and security fixes on main (rebasing the feature branch as needed).

[oxisto]

Understandable. Since "main" is now the to-be-v6, we can still merge it, after we agree on a name for key-type.

Probably outside the scope of this PR, maybe we can chat on Slack/email.

But wdyt about keeping main as v5 and having a long-lived v6.0.0-rc.1 (or v6.0.0-beta.1) branch with all the breaking changes? Keep in mind we'll need to change the go.mod, so /v5 users shouldn't be affected and we can continue to add bug and security fixes on main (rebasing the feature branch as needed).

-> mail ;)