Consider dropping Universal Module Definition (UMD) bundle

[jonkoops]

Checklist

• I have looked into the Readme and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

Since version 4 of this library is going to contain breaking changes (#175) to the Universal Module Definition (UMD) bundle, we might want to consider dropping it entirely. UMD was imagined when there were no module loaders on the web, which is no longer true now that we have JavaScript modules.

Describe the ideal solution

Remove the UMD bundle and recommend users to use the official module system that JavaScript provides.

Alternatives and current workarounds

Keep distributing the bundle, which likely nobody will use as it would require an explicit upgrade and migration steps.

Additional context

See discussion under #174

[jonkoops]

@frederikprijck to get back to your earlier comment #174 (comment):

I have a feeling you both have a strong reason to drop it, while i believe don't see the issue.

My main issue is long term maintenance, this code will be around for the entire 4.0 lifecycle, and it's an afterthought for most if not all tooling these days. Realistically those that are still using UMD are very unlikely to be actively maintaining projects, let alone upgrade and perform migrations (such as #175).

My opinion is to keep it, even if there are alternative paths for those users to migrate. I want to avoid unneccesarily breaking users beyond things that are needed, especially given this lib is used extensively.

The thing is, if we are deciding to make these users perform the aforementioned migration steps, we might as well take the extra step and pull it entirely. Especially since this will only be used in legacy applications.

[jonkoops]

Update, we're looking to perhaps keep the UMD bundle backwards compatible (#181), so this might soon not be relevant anymore.

[frederikprijck]

Thanks for moving this into an issue.

Keep distributing the bundle, which likely nobody will use as it would require an explicit upgrade and migration steps.

We do support UMD in pretty much all of our JavaScript SDKs, and want to keep that if it doesn't cause any current issues.

Especially since this will only be used in legacy applications.

Legacy applications shouldn't mean they are unable to use our SDK.
E.g. people might be using this with IE11 (no importmap). And even though this isn't something we support, or even recommend, I believe there is no reason to break them more than necessary when keeping support around asks no effort and has no negative impact on any of our other users (if one of the latter two would be different, I would strongly opt to remove it but that is not the case).

[jonkoops]

Closing this for #181