build!: add support for ESM and drop support for CommonJS

[rolandjitsu]

What kind of change does this PR introduce?

• Bug Fix
• Feature
• Refactoring
• Style
• Build
• Chore
• Documentation
• CI

Did you add tests for your changes?

• Yes, my code is well tested
• Not relevant

If relevant, did you update the documentation?

• Yes, I've updated the documentation
• Not relevant

Summary

Fully migrated the package to ESM and dropped support for CommonJS.

Does this PR introduce a breaking change?

Yes. Any use of this package that does not support ESM will no longer work.

Other information

[edemaine]

Looks good to me! (having read but not tested the changes)

[rxmarbles]

What is the reasoning for ESM only? I'm trying to catch up but I'm on vacation at the moment. Can I get some context @rolandjitsu ?

[rolandjitsu]

What is the reasoning for ESM only? I'm trying to catch up but I'm on vacation at the moment. Can I get some context @rolandjitsu ?

Checkout #66 and the original #64 for some context.

I've initially tried to keep support for commonjs, but a bump of node was needed, then I got into some issues with the lock file, which needed an update as well. Then other deps caused issues, etc.

To me it kind of seems that moving to ESM is the right thing to do, despite the fact that the consequence of that means some users (not sure if there is a way to show a percentage) will need to move to ESM as well, which I think that's inevitable (given that even node 18 will reach EOL next year some time - https://nodejs.org/en/about/previous-releases).

This simplifies the package in terms of build (there's nothing to build anymore) and size (just a couple hundred bytes vs kb).

We can keep the v2 version as a maintenance branch (we can update the release workflow to release from a v2.2.x branch) and patch it when necessary (we've hardly had any updates within years), but it'll require some work to make it work with pinned down versions of packages, and v3 will be fully ESM.

Let me know if that makes sense.