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: #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 #15479 (comment)

[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: microsoft/vscode#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: #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.

[bobbyg603]

@josdejong you can get around this by using an index.ts file.

In the index.ts file do the following:
export { MyClass } from 'src/my-class.js'

In your test just import the file directly instead of via the index file:
import { MyClass } from 'src/my-class'

[josdejong]

Thanks for sharing your workaround @bobbyg603 . I'm not sure how that would work for the imports inside src/my-class.ts, (nested). You can't change that dynamically depending on your context (testing or actually using).

It feels to me like there is a serious mismatch between plain ES modules (requiring actual existing paths with proper file extensions) and TypeScript code (relying on "smart" nodejs module resolution, not requiring file extensions, and (implicitly) changing the (implicit) file extensions from .ts to .js when compiling). I can't understand this issue is marked "Working as intended" in #40878 (comment), this is a problem that needs to be addressed.

Most logical to me would be to write imports with *.ts extension in your code (matching the actual file extension). And when compiling, have TypeScript replace *.ts extensions with *.js, matching the actual file extension of the compiled file (which is changed to *.js by TypeScript). TypeScript changes the file extensions from *.ts to *.js, so logically it should also fix corresponding imports.

[thomas-mindruptive]

Facing the same problem.

In most scenarios, we use webpack. But for simple scenarios and samples, e.g. for our TS-training for developers, we want to use plain TS files and JS modules without the complexity of another transpiler like Babel/webpack.
It looks odd in training classes when you try to explain the beauty of TS and then have to stutter something like "TS never changes outputted strings". Or you have to tell them that it will get better with webpack.
=> "The simple case is ugly but it looks good in the more complicated case when we use more tools."

This means:

• On the client/browser, TS needs a transpiler to transpile to some non-ECMASCRIPT-modules.
• If you go go for "import ./myModule.js", IDEs might mark it as error.
• Other ALM-scripts which parse source-code (testscripts, mock-scripts, build-scripts, deploy-scripts, ...) might get confused.

Why not add an option to tsconfig and leave it to the developer to use it or not?
We know that is is not "pure doctrine" but for many cases it will work. One could also emit a warning "will only work with static files" or something like that.

I'm aware that "import ./myModule" could resolve to something which is not a static file on the web-server. E.g. a web-service dynamically resolving and returning js-code.

In any case, please such an option would leave it to the developer's resonsibility how to transpile it.

[ioslh]

add .js extenstions on imports when the output is esm/es2015

I think add .js extenstions on imports when the output is esm/es2015 would be the only correct behaviour, because The file extension is always necessary for relative specifier in esm.

[pwhissell]

@ioslh I'm trying to get eslint to be able to ensure ".js" extensions are never forgotten
any thumbs up or help in trying to make my PR be accepted would be appreciated:
import-js/eslint-plugin-import#2033

[djfm]

TypeScript developers, please, do whatever the hell you want with file extensions, this debate has been going on for years, I don't care, your mind is set, fine. But just document this very basic thing in a place that's easy to find: how on earth do I run the JavaScript emitted by tsc when "module" is set to "ESNext"? That will save a lot of people a lot of time. Most people understand "transpiles to JavaScript" as "transpiles to working JavaScript". But this is not the case.

[TheBoneJarmer]

I'm hitting this exact same issue. I'm not using webpack, just plain typescript and my javascript output is broken because the .js extension is missing. How on earth can this not be a bug? What am I supposed to do instead?

[RA80533]

@TheBoneJarmer If you're just doing plain TS and JS, use the would-be filename as the import specifier like so:

import { version } from "./version.js";

[djfm]

The problem with this solution is that if you have an "outDir" different than the default, i.e. a setup where transpiled files don't live beside the .ts files, most tools will freak up and that's not a nice development experience. I was so pissed-up buy this that I built this monstrosity: https://www.npmjs.com/package/add-js-extension You can install it and have it watch your "outDir" and it will quickly and transparently add the .js extension where appropriate to the transpiled files as they appear / are updated by tsc. It seems to be working well. Only missing major feature is that I currently don't rewrite the source-maps but it doesn't seem to matter much since the changes I make in the js files are only adding 3 chars to some import statements at the end of some lines. No line offets, no changes to any place where you would be likely nor even able to set a breakpoint anyways. Give it a go and let me know of any issues you might find! There are webpack modules that do the same thing, but my solution is much less invasive: keeps file and directory structure, no bundling, no config. I spent a considerable amount of time reading the obscure ESM spec and I'm pretty confident my tool doesn't do anything unwise. I actually think TS has it wrong, as the ESM spec clearly states that there is no such thing as a default file extension. So you should "import foo from '. /foo.ts'" and that should transpile to "import foo from './foo.js'". I don't see any deviation from JS here. "import foo from './foo'" seems just wrong.

…

On Thu, Jul 29, 2021, 22:43 RA80533 ***@***.***> wrote: @TheBoneJarmer <https://github.com/TheBoneJarmer> If you're just doing plain TS and JS, use the would-be filename as the import specifier like so: import { version } from "./version.js"; — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALESE6S37QUCIGMC3IKOTLT2G4NRANCNFSM4SA23LJQ> .

[TheBoneJarmer]

Thanks for the replies guys. Personally I entirely agree with @djfm. I am grateful for the workaround from @RA80533 though, don't take me wrong. But it is far from a good solution imho. And the reasons why are nicely explained by djfm. That said, you are not the only one who got that idea. I found another npm package through Google which does what I believe you do as well. It is called tsc-esm and is created by user @Gin-Quin.

[TheBoneJarmer]

That said. I also took my time to learn a bit more about the whole es6 module system and I also think javascript has a flaw here. Imho they should introduce something similar to what happens in urls with index.html. In most if not all web servers you never have to manually insert '/index.html' at the end of an url. When the path ends with a / the server automatically converts that to /index.html. When no file extension is added at the end of an import statement, the client should convert this first to .mjs. If no such file exists than to .js. And only then the client should throw an error if neither files were found.

Therefore I more or less can understand why typescript devs don't consider this a bug from their side. Typescript merely interprets the import statement for typescript purposes but may not be able to convert it that easily to esm. But I do think this should be a config option.

I mean, several users already created their own npm package out of frustration which I think shows how big this problem is. And they are right to be frustrated because my basic typescript app produces broken javascript right now, which is a definitely a bug from typescript. And the fact that typescript devs do not want to admit that is just plain ignorance and stupid. This will only push people away from using TS. And on top of that, the fact that they say they won't do a thing about it does pisses me off even more.

Imho the tsc should stop conversion when an import statement cannot be converted to esm. Or throw a warning or hint that narrows down to "Due to limitations in the javascript language you are supposed to add a .js in your import statement or else tsc will produce broken code". And I'd be fine with that but not the way it is now.

[adamshaylor]

The recommendation to preemptively append .js extensions to TypeScript source is not only counterintuitive, it breaks ts-jest tests. It seems to me that TypeScript is in the wrong here. Why ban .ts extensions from import statements and encourage leaving them off altogether if the extension is resolved by the language server but not the compiler?

I just encountered this issue while attempting to port a library to TypeScript. I didn’t have to deal with it in prior projects because I was building apps with a bundler. Now that I’m emitting modules that can be tree-shaken downstream, this behavior, intended or not, leaves me in a bit of a pickle.

[counterposition]

@adamshaylor for what it's worth, vitest supports .js imports in test code and is largely API-compatible with Jest.

[caoxiemeihao]

Same confusion 🤔

[ProfXponent]

good to see this crazy conversation still going after 2 years

its amazing to me that something so basic as module resolution continues to be one of the most frustrating things about the nodejs ecosystem

I cannot wait for deno to gain more traction and put this issue to bed by enforcing esm

to the TS team, listen to your users and add a compiler flag

[tran-simon]

I've got a react app that's being bundled with webpack, and a pure typescript server. The 2 projects share some model classes.

If I import my classes using the standard Typescript syntax import MyClass from "./model/MyClass", I get the error:

cannot find module ... imported from ...

Alright, fine, I can simply add the ".js": import MyClass from "./model/MyClass.js"

... This causes webpack errors:

Module not found: Error: Can't resolve './MyClass.js' in "..."

This is infuriating

[LinksRay]

At first glance of the time of this issue, I think I'm lucky to find a perfect solution. Until scrolling to the bottom then I realize that I'm unlucky. So sad.

[claudioc]

So weird. In VSC if you Cmd+click on a import something from 'something.js'; you'll get to the .ts file, like VSC knows that this issue exists and "fixes it".

[djfm]

But wasn't it fixed? To my greatest surprise, in my latest project, I'm using relative imports in TypeScript without a file extension and the emitted JS just works!

…

On Thu, 3 Nov 2022, 15:51 Claudio Cicali, ***@***.***> wrote: So weird. In VSC if you Cmd+click on a import something from 'something.js'; you'll get to the .ts file, like VSC knows that this issue exists and "fixes it". — Reply to this email directly, view it on GitHub <#40878 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALESE7ZQOKDR7GJ3NTCYTTWGPGPFANCNFSM4SA23LJQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gastonmorixe]

@djfm no, unbelievable

[Nimmidev]

So weird. In VSC if you Cmd+click on a import something from 'something.js'; you'll get to the .ts file, like VSC knows that this issue exists and "fixes it".

This has nothing to do with VSC and also works in every other editor with the typescript LSP. Completely unrelated to this issue.

[jmrossy]

2023 now, and the flicker of hope for this feature is still alive!
See #47436 (comment)

[jogibear9988]

Here a few pull requests or issues, where i need only file extensions (.js) so I could use them in browser:

adobe/css-tools#90
wokwi/wokwi-elements#149 (comment)

I don't know why an extra option wich I created in my pull request could not be added...

[jogibear9988]

I know use a js script to add the extension afterwards, see the pull I created here on how to do: wokwi/wokwi-elements#150

[ernestostifano]

Just leaving my +1 here... can't believe this is still an issue.

Would be as simple as to allow using .ts extensions and then transform them into .js.

This would make everyone happy: hundreds of people asking for it and TS maintainers because TS principles will not be affected this way (read this comment).

Hope TS maintainers will reconsider this soon.

(Continues here)

[RyanCavanaugh]

Cross-posting this comment which explains that this is, very much intentionally, not something we are going to do.