Update module and moduleResolution in tsconfig.json?

[danielpeintner]

https://stackoverflow.com/a/71473145 provides some good input w.r.t. to module and moduleResolution.

At the moment we have the following settings

https://github.com/eclipse-thingweb/node-wot/blob/8dc6ed8d7a7fd24ef97d703c018a5ec1cd76481a/tsconfig.json#L5-L6

and possible settings are

Argument for '--module' option must be: 'none', 'commonjs', 'amd', 'system', 'umd', 'es6', 'es2015', 'es2020', 'es2022', 'esnext', 'node16', 'node18', 'nodenext', 'preserve'.

Argument for '--moduleResolution' option must be: 'node10', 'classic', 'node16', 'nodenext', 'bundler'.

nodenext does not seem feasible since it is a "floating" or bleeding-edge option. Useful to set the module emit version at least to 'node18'?

What is the advantage of using es variants, see https://blog.logrocket.com/commonjs-vs-es-modules-node-js/

[erossignon]

Using node16 allows us to create commonJs module that will work nicely if the consumer application is a ESM application. This is the situaion now in node-wot. However we still generate commonjs in dist and consumer cannot experience the full power of esm modules.

Adding the "type": "module" to package.json will cause typescript to generate esm javascript instead of common js. ( still using node16 , no need for nodenext !)

{
    "name": "@node-wot/binding-opcua",
    "version": "0.9.2",
    "main": "dist/index.js",
    "types": "dist/index.d.ts",
+    "type": "module",
    "devDependencies": {
.

The downside is that import has to be more explict

import { opcuaJsonEncodeVariant } from "node-opcua-json";
-import { schemaDataValue } from "./codec";
+import { schemaDataValue } from "./codec.js";
-import { OPCUACAuthenticationScheme, OPCUAChannelSecurityScheme } from "./security-scheme";
+import { OPCUACAuthenticationScheme, OPCUAChannelSecurityScheme } from "./security-scheme.js";

That's quite an easy change and we can already enforce adding a ".js" extension on our import statement as it doesn't break the node16 approach we are using today.

A more modern approach nowsadays it to generate nodejs module that can address both commonjs and esm. That can be achieved with tsup.

I'll make a demo in a dedicated branch if you want.