Modernizing Packages to ESM

[jonkoops]

Wanted to share this excellent article that I happened to stumble upon by @markerikson, sharing his experience modernizing packages to ESM. It was of special interest to me, as it has very close parallels to what I did for jwt-decode on the beta branch.

@frederikprijck I think the section on UMD support might also be relevant for us, Redux is a much more popular libray.

[frederikprijck]

Thanks for sharing, and ofcourse the work you put into the ESM/CJS support.

They have the same pain we've been through, and i agree with alot of the things they mention about how complicated it is. Also good to read about tsup, knowing we use it no, thanks for that 🎉.

Regarding UMD, i elaborated on my reasoning here

To reitterate in the context of this discussion, i believe as long as it doesnt cause issues or limitations, i believe it doesnt hurt keeping it. If it would cause issues, even for build tools, we can always consider removing it. But as mentioned, we maintain alot of SDKs, and we ship UMD for all (or most) of those (we even shipped a new major pretty recently for a couple of SDKs while keeping UMD as well).

When im back in the office next week, im happy to discuss UMD support in our larger surface area with our team, but we shouldnt drop this in a one off like this without considering our larger surface area.

[jonkoops]

The main benefit would be the reduced stack when we switch away from UMD, for example we can get rid off Rollup and related dependencies, plus remove some redundant configuration (see #191 to get an idea of the impact).

As mentioned before (#190 (reply in thread)), I sincerely doubt there are active UMD users, let alone those that would be upgrading. And those users might also be served perfectly by the existing 3.x version.

That said, it's up to you what we do with this. I just wanted to point out it could be a time saver in terms of maintenance long-term.

If you do talk to the larger team at Auth0, I think it would be interesting to mention tsup for TypeScript libraries (such as done in #191). It seems to make it easier to make good libraries, as it avoids a lot of the pitfalls mentioned in the article.

[jonkoops]

To those reading this thread in the future, we have decided to drop UMD support. More information can be found under #192.

[frederikprijck]

I do want to add that i think we definetly broke ie11 in the last PR to introduce arrow functions (not sure it worked before that PR, it's on my todo to check when back from holiday next week), which means we have more reasons to drop UMD, or make it output es5 for UMD if ie11 would be needed.

However, im not keen to explicitly support IE11, which might mean dropping UMD is a possibility as i see little need for UMD beyond IE11.

Let me get back to this.

[jonkoops]

Yeah, I don't think we should support IE11. It's market share isn't even tracked anymore in most metrics and is < 0.20% globally. It is full of security issues, and has not been supported by the vendor that created it for several years now. My personal opinion is that any browser not supported by it's own vendor, should probably not be supported.

I also highly doubt any application including the UMD bundle, and that has to be supporting IE11 (or any other legacy software for that matter), will be actively upgrading dependencies, or even have active maintenance. Hell, I'd wager these applications are not even using a package manager such as NPM in the first place, but just have the code checked in to the repo.