JavaScript Module System Migration (CommonJS to ESM)

CommonJS commonly uses `require()` and `module.exports`, while native ES Modules use `import` and `export`. That change affects how files load, how packages expose exports, and how tests and bundlers resolve the graph, as described in the [Node.js module documentation](https://nodejs.org/api/esm.html).

Node can treat `.js` files as ESM when the nearest `package.json` sets `"type": "module"`, or you can use `.mjs` explicitly. A `.cjs` extension forces CommonJS even inside a module package, according to [Node.js package rules](https://nodejs.org/api/packages.html).

When ESM imports a CommonJS package, Node creates a namespace wrapper and always provides a default export pointing at `module.exports`; named exports are not guaranteed to map cleanly. Check the dependency’s actual export shape instead of assuming every property becomes a safe named import.

Yes, `.mjs` and `.cjs` boundaries let teams move parts of a codebase incrementally while keeping some CommonJS files. The safe path is to test each package boundary, dynamic `require`, path handling, and test runner before changing the root `type` field.