How about removing the atob polyfill?

[cristobal]

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

There's no reason to actually have the atob polfyill bundled as part of the build output.
Even if the code is not used, there's no reason to bundle it.

This is the support table these days https://caniuse.com/?search=atob

Also supported from Node 16 and forward, 20 is LTS from october this year. Seems that this is legacy on Node perhaps a workaround should be used here instead.

Also the polyfill will always polyfill on the server even when not needed since it checks for the existence of it on the window that does not exists on the server. It should actually check on the globalThis first and then on the window instead that's how the core-js code does it.

Not sure even if the code is not used directly it can be tree shaken.
Most browser these days have support for atob.
Most people using babel and/or core-js will already bundle an drop in atob polyfill already.

Describe the ideal solution

1. Either completely remove the atob polyfill
2. Or add it as an optional import that can be used.
3. This allows people to decide themselves how to handle missing support for atob.
4. In addition to update the README accordingly.

[cristobal]

I can submit a PR for this if the idea is accepted.

[frederikprijck]

Thanks for reaching out and sorry for the delayed response.
I think that's not a bad idea, and should be easy to do for browsers but needs a bit more care for the node part as that might be a breaking change.

I will have an internal conversation with the team about this to see if and how we can proceed with this idea.

[cristobal]

No worries, just ping me when you have come to an conclusion.

[frederikprijck]

A bit different from just dropping the polyfill, but I opened #151, which mainly is about both the polyfill and better CJS/ESM support.

Because dropping the polyfill could be a breaking change (we could argue it isnt, but for a library with 5 million weekly downloads and no control over the environments, we figured we want to treat it as a breaking change to be sure), we took the time to update a couple extra things.

[cristobal]

A bit different from just dropping the polyfill, but I opened #151, which mainly is about both the polyfill and better CJS/ESM support.

Because dropping the polyfill could be a breaking change (we could argue it isnt, but for a library with 5 million weekly downloads and no control over the environments, we figured we want to treat it as a breaking change to be sure), we took the time to update a couple extra things.

Sounds good to me, yes totally agree that it would be best to threat it as an breaking change here. It also seems that the changes done in #151 would close #130 ?

Looking forward to the next major release, will test out #151 and see if the output plays nice with our setup. Thanks for sharing the upcoming changes 😊 🙏🏽

[frederikprijck]

will test out #151 and see if the output plays nice with our setup

If you would be able to test that that would be great, the more feedback we get the better! Feel free to leave any comments on #151 as needed.

[jonkoops]

Should we close this issue now that this has landed on the beta branch? Or do we want to keep it until this has been merged into main?

[frederikprijck]

Released as part of the latest beta, please try it out and provide any feedback so we can improve.

• https://www.npmjs.com/package/jwt-decode/v/4.0.0-beta.0
• https://github.com/auth0/jwt-decode/releases/tag/v4.0.0-beta.0