Typescript: Compiled JavaScript import is missing file extension

[jameshfisher]

TypeScript Version: 4.0.3
Search Terms: module es6 es2015 import file extension missing js ts bug 404

Steps to reproduce:

Create a main.ts:

import {foo} from './dep';
console.log(s, foo);

Create a dep.ts:

export const foo = 42;

Create a tsconfig.json:

{
  "compilerOptions": {
    "module": "ES2015"
  }
}

Then run:

npx tsc

Expected behavior:

The compiler generates JavaScript "which runs anywhere JavaScript runs: In a browser, on Node.JS or in your apps" (according to the TypeScript homepage). For example, it would be valid to create two files as follows; main.js:

import { foo } from './dep.js';
var s = "hello world!";
console.log(s, foo);

And dep.js:

export var foo = 42;

(More generally, the expected behavior is that the module specifier in the generated import must match the filename chosen for the generated dependency. For example, it would also be valid for the compiler to generate a file dep.xyz, if it also generated import ( foo } from './dep.xyz'.)

Actual behavior:

As above, except that in main.js, the import URL does not match the filename chosen by the compiler for the generated dependency; it is missing the file extension:

import { foo } from './dep';

When executing main.js in the browser, it requests the URL ./dep, which is a 404. This is expected, as the correct relative URL would be ./dep.js.

Related Issues: https://github.com/microsoft/TypeScript/issues/13422, voluntarily closed by the reporter for unknown reasons

[RyanCavanaugh]

TypeScript doesn't modify import paths as part of compilation - you should always write the path you want to appear in the emitted JS, and configure the project as necessary to make those paths resolve the way you want during compilation

[jameshfisher]

Thanks @RyanCavanaugh! Do you mean I should write import { foo } from './dep.js' in my source main.ts? That does actually seem to work! In that the compiler uses './dep.ts' to find the types of variables exported.

However, I find this surprising, because

• The recommendation everywhere else in TypeScript docs is to omit the file extension.
• If I try to import from './dep.ts', the compiler gives me error TS2691: An import path cannot end with a '.ts' extension. Consider importing './dep' instead. So apparently it's not possible to generate JavaScript imports that end in .ts?
• The module resolution docs don't say what's going on here. What logic makes this work? Is there a special case for .js, which is mapped to .ts?
• I can't find a rationale for this design anywhere.

[RyanCavanaugh]

TS never takes an existing valid JS construct and emits something different, so this is just the default behavior for all JS you could write. Module resolution tries to make all of this work "like you would expect"

See also https://github.com/microsoft/TypeScript/issues/15479#issuecomment-300240856

[jameshfisher]

@RyanCavanaugh that principle makes sense. My remaining confusion then is why the docs and compiler encourage omitting the file extension, if "you should write the import path that works at runtime". Maybe this encouragement is designed for a JS runtime that demands that you omit the file extension. But the runtimes I'm aware of are browser, ES modules, and Node.js, none of which make this demand.

[RevealedFrom]

@RyanCavanaugh Writing "./dep.js" doesn't sound logical. The file dep.js does not exist in the Typescript universe. This approach requires the coder to know the exact complied output and be fully aware of the compiled environment. It's like having to know the CIL outputted and modify it here and there in order to code in C# successfully. Isn't the whole idea of Typescript to abstract away Javascript?

import { foo } from "./dep" is legitimate Typescript, and it provides the information for Typescript to resolve all that is needed to type check and make the code compile successfully. So, the compiled output should work. Typescript should not be generating syntactically incorrect Javascript.

IMHO, this issue should be a bug.

[RyanCavanaugh]

The whole idea of TypeScript is to add static types on top of JavaScript, not to be a higher-level language that builds to JS. The C# / IL comparison is not apt at all.

There's literally no line of undownleveled JavaScript code you can write where TS intercepts some string in it and changes it to be something else. This is 100% consistent with TS behavior in every other kind of JS construct; it would be frankly bizarre to have import paths be the one thing that we decide to go mess with.

[jogibear9988]

problem is, ts does not only need to add '.js', there are complexer resolution strategies.

i would like it, if there would be a way of calling a plugin after transpilation had been done, so I could fix the import names with that.
I know I could use a bundler / build system, but we ship directly the code typescript generates, without an additional build step. at the moment we fix the import path's in our own webserver.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[ryancwalsh]

@RyanCavanaugh @jameshfisher I was about to post a new bug about TypeScript but then the template encouraged me to search again, and I found this issue, which might be similar enough.

But I'm still confused, even reading above.

Here is the "bug" I submitted to the "vscode" repo, and that team rejected it and said that I should submit to the "TypeScript" repo here: https://github.com/microsoft/vscode/issues/108872

It seems that people trying to write TypeScript in VSC face this dilemma of choosing between:

1. VSC shows an error (red underline), but the code works, or:
2. If we follow the VSC error tooltip's suggestion, it will "resolve" the error in the editor, but then the code won't run.

I'm getting this error and don't understand why:

An import path cannot end with a '.ts' extension. Consider importing '_______' instead. ts(2691)

See also: microsoft/TypeScript#11235 (comment)

[jameshfisher]

So far, I have had success with @RyanCavanaugh's suggestion to "always write the path you want to appear in the emitted JS, and configure the project as necessary to make those paths resolve the way you want during compilation".

But I am still confused because this advice contradicts the compiler and docs and ecosystem, which all encourage omitting file extensions.

[ryancwalsh]

Yeah that doesn't feel right. I really don't understand. I can't think of any principle where it would make sense to throw a prominent red error for something legal.

[josdejong]

Same issue here. Adding a .js in the import inside a TypeScript file does allow to compile it with the TypeScript compiler and will output files with working ESM imports.

However, when I add .js extensions on the imports, I can't get testing working. Tried with Mocha and Jest, but no luck so far: they complain the files with .js extension don't exist, which is correct, those files don't exist since they actually have a .ts extension.

I would love to see the TypeScript compiler add .js extenstions on imports when the output is esm/es2015.