Drop CommonJS Support #881
Description
[@ctavan I know we've discussed this previously, but I recently had to rework the logic for detecting module type in npmgraph and it reminded me of just how ridiculous this ESM+CJS world is. It's just cemented in my mind that the dual-package "solution" is long-term horrible and that package owners should be more proactive about addressing the problem.]
CommonJS is an inferior module format and this "dual module" world the JS ecosystem finds itself in is awful. "Dual module" packages...
- ... have more complicated build tooling
- ... have more complicated testing and CI
- ... have larger package footprints
- ... are more complicated to process by downstream tools
... all of which results in more pain for users and maintainers.
Sadly, nobody seems able to do anything about this. Ideally the NPM and Node organizations would be actively advocating for CJS to be deprecated, but they seem content handcuffed(?) to limiting their involvement to baby steps that do little to address the underlying problem. Thus, I see the burden as falling on project maintainers.
I know there's no real demand for this from uuid users, but that's to be expected. Nobody ever complains about a project supporting too many platforms. But we're at a good place to be making this move. RFC9562 is fully supported, we have TS support, and overall uuid is mature and stable.
I expect most users won't notice. They'll be using toolchains that deal with modules in either format. Those that care can pin their dependency to uuid@11.
(Note: My "users won't care" opinion is informed by my experience making mime ESM-only. Dropping CJS support for that library took place with barely a peep from users.)