Ability to create projects with ESM pre-configured

[vemv]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

While I understand that NestJS, the framework, is written in CommonJS, and that there's no immediate problem with that, I'm under the impression that users most often want their apps to be set up to consume/emit ESM.

The NestJS CLI creates apps assuming CommonJS, so pure ESM libraries won't work out of the box.

Adapting a NestJS app to work with ESM needs somewhat detailed knowledge, and misc surgery. Some folks don't even know it's possible to make it work, which isn't a good look for NestJS.

Describe the solution you'd like

A new option in the wizard that expressed the user intent to have their project use a ESM compilation pipeline.

The differences seem relatively tiny, and described in this document:

• Make sure you are using TypeScript 4.7 or later.
• Add "type": "module" to your package.json.
• Replace "main": "index.js" with "exports": "./index.js" in your package.json.
• Update the "engines" field in package.json to Node.js 18: "node": ">=18".
• Add "module": "node16", "moduleResolution": "node16" to your tsconfig.json. (Example)
• moduleResolution must be set to node16 or nodenext, NOT node!
• Use only full relative file paths for imports: import x from '.'; → import x from './index.js';.
• Remove namespace usage and use export instead.
• Use the node: protocol for Node.js built-in imports.
• You must use a .js extension in relative imports even though you're importing .ts files.

Teachability, documentation, adoption, migration strategy

If this option was successfully implemented, perhaps it could eventually become the default?

What is the motivation / use case for changing the behavior?

The ability to consume pure ESM libs, and the reduced burden given to users.