Let's Say Goodbye to CommonJS (CJS)

[babakfp]

Node should stop the BS and remove CJS once and for all.

1. Node started with CJS.
2. Added ESM.
3. Added the { "type": "module" } option.
4. Developers/tooling started maintaining both syntaxes.
5. Added syntax detection by default: https://nodejs.org/en/blog/release/v22.7.0#module-syntax-detection-is-now-enabled-by-default.
6. The result: When to make --default-type=module the Node.js default TSC#1445 (comment).

So many discussions, frustration, confusion, work, etc went into this stupid thing, and Node still can'ts stop being obsessed with CJS.

Stop the idea of being backward compatible. Even browsers aren't always backward compatible. They aren't even compatible with each other.

Just hard delete it in a new major version.

• Developers needed to learn about both CJS and ESM.
• Developers needed to deal with stupid compatibility issues.
• Beginners needed to deal with CJS errors when trying to run their first Node code.
• Developers needed to add the stupid { "type": "module" } option.

Etc...

Just stop.

---

Never mind. I'll try out Deno again, and hopefully it's less trash.

[RedYetiDev]

Stop the idea of being backward compatible. Even browsers aren't always backward compatible. They aren't even compatible with each other.

While browsers aren't always backward compatible, programming environments that have established ecosystems depend on it. Node.js has a vast array of libraries and projects built using CJS. Forcing developers to rewrite or abandon countless existing projects would create a significant burden.

Just hard delete it in a new major version.
Developers needed to add the stupid { "type": "module" } option.

Node.js is offering a path to transition, rather than abruptly forcing everyone to switch to ESM. The coexistence of CJS and ESM lets developers migrate at their own pace, which is especially important for large codebases and legacy systems. The { "type": "module" } option and syntax detection are tools to make this smoother, not more complex.

Developers needed to learn about both CJS and ESM.

While it's true that developers need to manage both CJS and ESM for now, that's not unusual in the evolution of programming environments. Tooling has already improved significantly, and Node.js’s approach gives time for libraries and applications to adapt. Eventually, the ecosystem might? be more ESM-centric, but forcing an immediate and hard switch would likely create more frustration than it solves.

Developers needed to deal with stupid compatibility issues.

Many legacy projects and libraries rely on CJS and are deeply integrated with existing Node.js tools. Removing CJS would alienate developers and businesses that rely on these projects. A sudden break in compatibility would be damaging, as not every project can be easily migrated to ESM due to complexity, resources, or third-party dependencies.

Node still can'ts stop being obsessed with CJS.

Node.js’s approach is all about developer flexibility. It's not “obsessed with CJS,” but rather respecting its user base's needs. Transitioning to ESM is an ongoing process, and for many, maintaining CJS compatibility is essential for their workflow.

---

I've also marked this discussion as invalid Issues and PRs that are invalid. because, to me, it seems more of a rant than a question.

[RedYetiDev]

(Just FYI - I edited your comment to remove the unneeded block quote)

[RedYetiDev]

Hey, this discussion is exclusively for Node.js, so discussing Deno and Bun is off topic.