ERR_MODULE_NOT_FOUND, file extensions in imports using ES modules

[Ziothh]

Search Terms

ts-node, ERR_MODULE_NOT_FOUND

Expected Behavior

run my typescript es module files.

Actual Behavior

I have a project that looks like this

• package.json
• tsconfig.json
• src/main.ts
• src/module.ts

I have a "start" script in my package.json that I run via pnpm start that executes
ts-node ./src/main.ts. (I have also tried this with npm and it also didn't work)

When I run this I get the error "Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.". So I do as I'm told and I add it to my package.json and run it again.

Now I get this error: "TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for [path-to-project]/src/main.ts"

I manage to resolve this error by adding "--esm" to my start script like this: ts-node --esm ./src/main.ts. If I run my start script I get a new error: "Cannot find module '[path-to-project]/src/module' imported from [path-to-project]/src/main.ts"

I can surpass this error by doing this:

// main.ts
// -- 
import { myLog } from "./module"
// --
// ++ 
// ** Add a ts-ignore because typescript doesn't like me adding the file extension. */
// @ts-ignore
import { myLog } from "./module.ts"
// ++

Now my code runs but I have some issues with this

• I don't like adding ".ts" behind every import. This defeats the purpose of auto-imports
• Typescript really doesn't like me adding a file extension in an import statement.

How can I make my code work with ts-node by removing the ".ts" extension in the import statement?

Minimal reproduction

// main.ts
import { myLog } from "./module"

console.log("hiii")
myLog()

// module.ts
export const myLog = () => console.log("module imported")

Specifications

• ts-node version: 10.8.0 | 10.7.0 (tried both versions)
• node version: 16.15.0 | 18.2.0 (switched using nvm)
• TypeScript version: 4.7.2
• tsconfig.json:

{
    "compilerOptions": {
        "target": "ESNext",
        "module": "ESNext",
        "skipLibCheck": true,
        "sourceMap": true,
        "outDir": "./dist",
        "moduleResolution": "node",
        "removeComments": true,
        "noImplicitAny": false,
        "strictNullChecks": true,
        "strictFunctionTypes": true,
        "noImplicitThis": true,
        "noUnusedLocals": false,
        "noUnusedParameters": false,
        "noImplicitReturns": true,
        "noFallthroughCasesInSwitch": true,
        "allowSyntheticDefaultImports": true,
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "allowJs": true,
        "emitDecoratorMetadata": true,
        "strict": false,
        "resolveJsonModule": true,
        "typeRoots": ["src/types", "./node_modules/@types"],
        "baseUrl": ".",
        "paths": {
            "@entities": ["src/entities/index.ts"],
            "@entities/*": ["src/entities/*"],
            "@config/*": ["src/config/*"],
            "@helpers/*": ["src/helpers/*"],
            "@mytypes/*": ["src/types/*"],
            "@server/*": ["src/server/*"]
        }
    },
    "exclude": ["node_modules"],
    "include": ["./src/**/*.ts"]
}

• package.json:

{
    "type": "module",
    "devDependencies": {
        "@types/node": "^17.0.36",
        "ts-node": "10.7.0",
        "typescript": "^4.7.2"
    },
    "scripts": {
        "start": "ts-node --esm ./src/main.ts"
    }
}

• Operating system and version: MacOS

[cspotcode]

https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#type-in-package-json-and-new-extensions

That section has a detailed breakdown of how file extensions work. I recommend reading it thoroughly. Remember that this is the way that TypeScript has chosen to do things, so ts-node follows along with those rules. Even if you are not using "module": "NodeNext", those rules still apply.

Worth noting also that the --esm flag can be configured in your tsconfig.json if you prefer putting stuff in tsconfig instead of passing command-line flags. Your choice, whichever you prefer.

When I run this I get the error "Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.".

Can you copy-paste the complete terminal output that you see when getting this error? I suspect that there is additional context, perhaps some lines of output preceding or following that error. It will help to know what is giving you this error. I suspect node is giving it to you, but could also be typescript.

[Ziothh]

Thanks for the quick response.

I've read the docs you sent me. So Node (& Typescript also) want you to always specify the file extension, right? Even though I've specified my module type in package.json.

Visual Studio Code yells at me if I do this. It's running Typescript version 4.7.2
The error: An import path cannot end with a '.ts' extension. Consider importing './module.js' instead.ts(2691).

This error also also gets logged in the console if I run my files via ts-node

I only manage to get my code working if I prepend my import statements with a "// @ ts-ignore"

Can you copy-paste the complete terminal output that you see when getting this error? I suspect that there is additional context, perhaps some lines of output preceding or following that error. It will help to know what is giving you this error. I suspect node is giving it to you, but could also be typescript.

Here are the errors I get before adding "type": "module"

Worth noting also that the --esm flag can be configured in your tsconfig.json if you prefer putting stuff in tsconfig instead of passing command-line flags. Your choice, whichever you prefer.

Thanks. I'll add it to my tsconfig

[cspotcode]

My guess is you're still stuck putting a .ts extension in your import statements when you should put a .js extension instead. Try it even if it seems wrong; it'll work.

[Ziothh]

Sadly this works. Thanks for the help even though this isn't a ts-node problem but a typescript problem.

It feels really wrong to put a ".js" extension behind my ts imports... I'm also bummed out that my auto imports don't auto add the extension.

Hopefully I'll find some kind of import resolver that just adds the extension behind the scenes... For now switching to "module": "Node16 in my tsconfig does the job.

[cspotcode]

Auto-imports can be configured to add the extension. There's a vscode setting for it; they also automatically mimic style of the other imports in the file.

[Ziothh]

Auto-imports can be configured to add the extension. There's a vscode setting for it; they also automatically mimic style of the other imports in the file.

Alright I'll have a look.

[DougMidgley]

TLDR version: where using type: module, put .js even when you are importing .ts. This will work even though it seems counter intuitive :)

[Ngorror]

Thanks to this thread I managed to run and debug my TS even without // @ts-ignore

node --watch --loader ts-node/esm ./src/index.ts

here is an example of my package.json and tsconfig.json

[hlau-square]

you can also try adding this flag
--experimental-specifier-resolution=node

[pavelgorbach]

you can also try adding this flag --experimental-specifier-resolution=node

or adding this to tsconfig.json

"ts-node": {
    "esm": true,
    "experimentalSpecifierResolution": "node",
}

[ky1ejs]

Thank the lord for this comment and you @pavelgorbach 🙏🏼🙏🏼. This was killing me.

[gugol2]

you can also try adding this flag --experimental-specifier-resolution=node

or adding this to tsconfig.json

"ts-node": {
    "esm": true,
    "experimentalSpecifierResolution": "node",
}

That did not work for me, sorry.
I am not sure to what point the other parameters of the tsconfig file may be clashing with this parameter... Here is mine:

{
  "compilerOptions": {
    "target": "ESNext", // Change as needed
    "module": "ESNext", // Use 'ESNext' for ESM
    "strict": true, // Enable strict type checking
    "esModuleInterop": true, // Enables emit interoperability between CommonJS and ES Modules
    "skipLibCheck": true, // Skip type checking of declaration files
    "forceConsistentCasingInFileNames": true,
    "rootDir": "./src", // Root directory of your source files
    "outDir": "./dist", // Output directory for compiled files
    "types": [
      "jest",
      "node"
    ],
    "moduleResolution": "node", // Module resolution strategy -> Tackle this
    "allowJs": true,
  },
  "include": [
    "src/**/*"
  ], // Adjust paths as needed
  "exclude": [
    "node_modules",
    "dist"
  ]
}

[Helveg]

FWIW, when code reaches high McGabe's humans simply can't follow anymore, and we are way beyond this point with the 3 different configuration points (package.json, tsconfig, ts-node), 10 different module types, 2 different type types, 3 different set of module resolution rules, 2 different sets of rules dealing with extensions, bunch of TS compiler options, ts-node options, ...

It's going to be a rough time transitioning to ESM.

[AckerApple]

Boy oh boy hello from the future and it is painful BUT managable.

One of my favorites about why ESM wants those file extensions, is because our browser themselves now supports import/export syntax with <script type="module">import * as something from 'x.js'</script> but for that to work a request to a server must be made and that must include the extension to get there.

Now however I'd argue that a file bundler could just produce the .js extensions but whatever it is still cool that we can now write vanilla non-compiled JavaScript code with import/export statements.

Something tells me too that this will allow us to more easily import only the files that are used by one javascript component with far less compiling/bundling because import/export supported native in browser now.