update config settings and readme

[fox1t]

This is a breaking change.

• version bump to 2
• module and moduleResolution are set to NodeNext, which follows the Node.js ESM vs. CJS resolution (exports and main fields)
• adds more examples to readme based on the use case

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[fox1t]

@fastify/typescript FYI

[mcollina]

I'm not convinced by doing this change right now. It means that our typescript modules would become ESM.

As far as production system goes, ESM is almost ready, as ESM loaders will become stable soon.

Out of prudence I would keep it commonjs still.

The other reason why I'm on the fende is that it does not make much sense to produce ESM with TS and stick all other modules as commonjs.

[fox1t]

I'm not convinced by doing this change right now. It means that our typescript modules would become ESM.
This is not true. Let me explain how NodeNext works.

NodeNext says TypeScript to follow Node.js rules around how it resolves ESM and CJS files. In practice, this means that TypeScript will read the nearest package.json file in the scope and search for the "type" field or the absence of it. The rule, therefore, is simple.

If type is absent or "type": "commonjs" the emitted code will be CommonJS, with .js extension. Moreover, tsc will complain if you use ESM-only properties/features in your files. If you really want to emit .mjs files, use .mtsextension.
On the other hand, if "type": "module" is set, the sources will be compiled to the ESM with the .js extension. If you want to emit .cjs files, use the .cts extension.

The "following the Node.js rules" goes also for the exports field. If the type is set, regardless of the value, TypeScript will check the exports field to know where the compiled code and the types are located. If the type field is not set, it will check for the old main and types fields.

TypeScript should have been doing this since the beginning, but they needed to wait on Node.js to implement ESM.

That said, this is a breaking change because we are increasing the minimum Node.js version from version 10 to version 16 since we are changing the target of the compilation to ES2022 from ES2018.

I hope this helps you understand how it works and why it is crucial to use this retro-compatible configuration.

[mcollina]

Could you add the above in the README? Thx!

[fox1t]

Could you add the above in the README? Thx!

Done!

[rozzilla]

LGTM

[mcollina]

lgtm