Don't define structs as top-level constants

[makimoto]

Changes

Structs defined in lib/auth0/mixins are currently defined as top-level
constants (e.g. AccessToken). However, these names are popular and can
conflict with existing classes and break the client application.
Therefore, I'd like to put them as children of Auth0 module.

References

Closes #201

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of Ruby

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors
• Rubocop passes on all added/modified files
• All active GitHub checks have passed

[joshcanhelp]

Thanks once again @makimoto!

The problem here, though, is that this would be a breaking change for anyone using these structs, correct? I think this is a positive change but would have to be released in a major (if I understand correctly).

[makimoto]

@joshcanhelp Probably, yes.
In this patch, I changed AccessToken, ApiToken, and Permission.
If my understanding is correct, AccessToken and ApiToken are used as return values, so they may not break compatibility unless a client application checks their types. (e.g. if response.is_a?(AccessToken))
However, Permission is used as a parameter for some methods (e.g. add_role_permissions) so it requires modifications at client applications' end.

[joshcanhelp]

@makimoto - The Permissions struct can change because that's not been released yet, I'm fine with that. For the others, it's probably best to just add a # TODO there and we'll address in a major.

[pjo336]

What's the status on this? Anything we could do to move it along? We have some conflicts

[zinosama]

Hey @joshcanhelp the Permission struct change is breaking our application. What are the remaining blockers before we can get this merged? Happy to help move this forward 😄 Please let me know.

[qortex]

Any chance that could move forward?

[copiousfreetime]

I also just encountered this issue and was about to do a pull request for it and saw this. Please do move this forward and release a 5.0 version.

[qortex]

I also just encountered this issue and was about to do a pull request for it and saw this. Please do move this forward and release a 5.0 version.

That would be great, but it seems Auth0 has dropped support for this gem, or at least designated maintainers are no longer taking care of the repo.

@joshcanhelp Can you share Auth0 plans? Should we fork and go on with it ourselves? Thanks for your visibility on this matter.

[davidpatrick]

Hey everybody, we apologize for the delay on this. We have kept putting this off until we had more planned for a 5.0 release. Considering that we still don't have anything major planned for this SDK, I will move forward with this and #171 for a 5.0 release.

[qortex]

Great, thanks for your work!