Problem using ts-node with NodeNext modules

[PavelTurk]

I have two projects - angular 13 library and my-tool.

My-tool

My-tool analyzes angular project .ts files and does some processing.... My-tool has a bin section in package.json. So, to run my-tool I do in angular library root npx my-tool. My-tool is created via rollup and has the following shebang: #!/usr/bin/env ts-node. Test code in my-tool is the following (it just creates instances of the passed classes from angular library):

for (let i = 0; i < classes.length; i++) {
      let classPath = classes[i];
      import(path.resolve(this._basePath, classPath)).then(module => {
          for (const className in module.default) {
            let c = new module.default[className]();
            console.log(c);
          }
      });
    }

Angular library
tsconfig:

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "core": [
        "dist/core/core",
        "dist/core"
      ]
    },
    "outDir": "./dist/out-tsc",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "strictNullChecks": false,
    "noImplicitOverride": true,
    "noPropertyAccessFromIndexSignature": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "sourceMap": true,
    "declaration": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2017",
    "module": "es2020",
    "lib": [
      "es2020",
      "dom"
    ],
    "typeRoots": [
      "node_modules"
    ]
  },
  "angularCompilerOptions": {
    "enableI18nLegacyMessageIdFormat": false,
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  },
  "ts-node": {
    "esm": true,
    "experimentalResolver" : true,
    "compilerOptions": {
      "target": "es2017",
      "module": "NodeNext",
    }
  }
}

package.json

{
...
  "private": false,
  "type": "module",
...
}

and when in my angular library root I run npx my-tool I get:

/home/pavel/mylib/projects/core/src/abstract-foo-entity.ts:9
export class AbstractFooEntity {
^^^^^^

SyntaxError: Unexpected token 'export'
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1026:15)
    at Module._compile (node:internal/modules/cjs/loader:1061:27)
    at Module.m._compile (/home/pavel/mylib/node_modules/ts-node/src/index.ts:1597:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Object.require.extensions.<computed> [as .ts] (/home/pavel/mylib/node_modules/ts-node/src/index.ts:1600:12)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:168:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)

Could anyone say how to fix it? It is the second day I am trying to fix this problem.

[cspotcode]

Try rewriting shebang to be this:

#!/usr/bin/env -S ts-node -vvv

Then try it again with this:

#!/usr/bin/env -S ts-node --showConfig

This is not intended to fix the problem. Rather, it will cause ts-node to output useful diagnostic information.

[PavelTurk]

With shebang #!/usr/bin/env -S ts-node -vvv, the output is:

ts-node v10.8.1 /home/pavel/mylib/node_modules/ts-node
node v17.3.0
compiler v4.6.4 /home/pavel/mylib/node_modules/typescript/lib/typescript.js

With shebang #!/usr/bin/env -S ts-node --showConfig the output is

{
  "ts-node": {
    "experimentalResolver": true,
    "esm": true,
    "cwd": "/home/pavel/mylib",
    "projectSearchDir": "/home/pavel/mylib/node_modules/my-tool/dist",
    "project": "/home/pavel/mylib/tsconfig.json"
  },
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "core": [
        "dist/core/core",
        "dist/core"
      ]
    },
    "outDir": "./.ts-node",
    "forceConsistentCasingInFileNames": true,
    "strict": false,
    "strictNullChecks": false,
    "noImplicitOverride": true,
    "noPropertyAccessFromIndexSignature": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "sourceMap": true,
    "declaration": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2017",
    "module": "es6",
    "lib": [
      "es2020",
      "dom"
    ],
    "typeRoots": [
      "/home/pavel/mylib/node_modules"
    ],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "inlineSourceMap": false,
    "inlineSources": true,
    "noEmit": false
  }
}

[cspotcode]

Looking at the output of --showConfig, we can see that it is using tsconfig /home/pavel/mylib/tsconfig.json with "module": "es6" and "moduleResolution": "node" instead of NodeNext. Since you said you want to be using NodeNext, we know you'll need to fix this configuration issue.

In particular, looking at the "ts-node" block in the output of --showConfig:

{
  "ts-node": {
    "experimentalResolver": true,
    "esm": true,
    "cwd": "/home/pavel/mylib",
    "projectSearchDir": "/home/pavel/mylib/node_modules/my-tool/dist", // <-- this is where ts-node begins to search for tsconfig
    "project": "/home/pavel/mylib/tsconfig.json" // <-- this is the tsconfig that it finds because `node_modules/my-tool/tsconfig.json` does not exist.
  },

[PavelTurk]

Thank you very much for your answer. As I understand "module" must be "NodeNext", but what should I set for "moduleResolution"? And another question, although I don't know where this es6 come from, mustn't ts-node work properly anyway? As I understand from your today's answer ts-node supports all types of modules.

[cspotcode]

As I understand "module" must be "NodeNext", but what should I set for "moduleResolution"?

It should also be NodeNext.

As I understand from your today's answer ts-node supports all types of modules.

But what if package.json "type" disagrees with tsconfig "module"? The benefit of NodeNext is that typescript compiles according to package.json "type" so there is no risk that you accidentally configure them differently.