We already do this for deno, and as we transpile from good TS, this should be fairly easy to wholesale. From my experience it's a matter of adding a single word to the transpiling tool.

Summary of the benefits (I'm missing a bunch, but I feel like this should not have been kicked down the can so I'll reiterate them here):

• Ability to implement HMR... all HMR tooling in Rollup is geared for ESM
• Ability to use import '@feathersjs/feathers' directly from the browser, without a build step or any additional tools... just use the script element with type=module.
• Ability to use in Node type=module projects without a finicky loader or experimental compatibility settings.
• Better tree shaking as loaders like vite can make much better assumptions
• Fixes 404 errors in UNPKG. Any package that depends on a package that doesn't declare a module export will not work with ?module set, which is necessary in some situations.
• Better Deno support
• Improved reliability in isomorphic
• Easier tooling and on boarding, as tooling becomes optional, especially in front-end code.
• Provides a good alternative for global namespace pollution... currently the recommended way to install is as a global... which could cause issues with other code. There are several other front end libraries using feathers as a name for things.
• Faster sandboxes... a tree shakeable Feathers should be faster to load with Turbo... rather than waiting a minute to clone, wrap CJS code, load it as a monolith, run it with training wheels... stack blitz and replit could boot from scratch even faster than it does now... even on slow connections
• Easier to read, more maintainable code. Currently if you import Debug, you can't be sure of what you're seeing, if it can be destructured (it can't) or what will happen. Destructuring Debug will cause major subtle problems... because of this, bundlers are very careful and treat your code as if you are a terrible programmer like whoever wrote Debug, meaning it will be slower than if you had used ESM.
• The cool kids will judge you for using CommonJS at school.

I've encountered this again while using a search-and-replace plugin to patch another Feathers issue. To use the plugin in a node module, the dependency I'm patching has to be a module too...

I've also seen issues with unpkg's module mode. There are also some performance benefits that can be had if we use module only settings in a few places like Vite. As we don't have HMR, and this is such a massive monorepo, every millisecond counts.

P.S. The same build tool that generates JS from TS can do it as an argument, and it does it with search and replace, so it does not significantly add to build time.

Looks like this has been surprisingly long in the making
https://github.com/feathersjs/feathers/pull/2665/files

The changes look fairly minor, there are just a lot of small ones. It seems like we can do it package by package.