Compiled JavaScript import is missing file extension
jameshfisher opened this issue · comments
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 tscExpected 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
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
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 meerror 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.
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)
@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.
@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.
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.
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.
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
@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:
- VSC shows an error (red underline), but the code works, or:
- 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)
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.
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.
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.
@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'
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.
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.
add
.jsextenstions 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.
@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
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.
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?
@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";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.
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.
When the path ends with a / the server automatically converts that to /index.html.
For a bit of clarity, this behavior is due to the way modern web authors tend to serve content. Web servers as a whole are glorified file systems. A request to / is semantically equivalent to inspecting the root directory yet, because web servers have optimized the browsing experience in a manner such that they aren't beholden to typical file system behaviors, that would-be directory request is often treated as a file request through some arcane redirection.
I think this issue should be reopened. The purpose of the TypeScript compiler is to build into a valid JavaScript code.
When the compiler is configured to target ES5, it creates valid ES5 code.
When the compiler is configured to target ES6, it creates non-valid ES6 code.
This is a bug, plain and simple: from on a perfectly valid TypeScript source, the compiler build a non-valid ES6 code:
lib.ts
Perfectly valid TypeScript code
export const start = () => {
}index.ts
Perfectly valid TypeScript code
import {start} from "./lib";
start();node dist/index.js
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '[...]/dist/lib' imported from [...]/dist/index.js
When the compiler is configured to target ES6, it creates non-valid ES6 code.
It creates non-valid ES6 code when given non-valid ES6 code. The first line in index.ts should be rewritten like so:
import {start} from "./lib.js";@RA80533, no, it creates non-valid ES6 code when given valid TypeScript code.
Typescript 4.3.5. When I build with tsc then run with node, it can't find the imports because they lack .js extensions.
I was able to work around this using --experimental-specifier-resolution=node on node 15.3.0, but this is obviously experimental. It also required setting "type": "module", which breaks ts-node and thus also nodemon which was calling ts-node. So I crafted my own pseudo-ts-node / nodemon combo using tsc --watch combined with nodemon called on the .js file that tsc outputs. My nodemon config for any interested:
{
"restartable": "rs",
"ignore": [".git", "node_modules/", "dist/", "coverage/"],
"watch": ["."],
"execMap": {
"js": "node --experimental-specifier-resolution=node",
},
"ext": "js,json,ts"
}
And my dev-server.sh:
(trap 'kill 0' SIGINT; yarn tsc --watch & yarn nodemon build/server.js)
The proposed workaround is to code with imports from .js files explicitly.
However, the assumption that modules can be resolved without .js or .ts extensions seems to be widespread. The official Typescript docs about modules use this example:
StringValidator.ts
export interface StringValidator {
isAcceptable(s: string): boolean;
}
ZipCodeValidator.ts
import { StringValidator } from "./StringValidator";
export const numberRegexp = /^[0-9]+$/;
export class ZipCodeValidator implements StringValidator {
isAcceptable(s: string) {
return s.length === 5 && numberRegexp.test(s);
}
}
I think the "right" way forward is to enable node, ts-node, and the like to handle imports without .js (the "node" module resolution strategy), rather than getting Typescript to modify the imports to add '.js' extensions. That will take a while. But the above workaround worked for me, without having to change all my imports to .js
@joshhansen but if you enable typescript to add .js it also would work on the web without transpile
I also just stumbled over this issue and as usual I find the justifications of "working as intended" as really questionable. There are various settings in the compiler which steer the module system. If I set "module": "commonjs" my typescript import statements are rewritten to require. There is also esModuleInterop which adds some extensions around the module imports.
While I agree that maybe the default behavior should be in the way that TypeScript leaves everything untouched, I also would say that it should/must be a TypeScript compiler setting to handle the mentioned use cases. I wanted to use TypeScript to create a small command line tool, which I can use in my GitHub Actions Workflow (without really making a reusable action) and it just does not work because the TypeScript output is not compatible with Node.js. Node.js seems to be usually a first class citizen in TS and here some very high level rules on the design goals (which IMO only partially apply here) prevent many people to use TS in such an obvious chain as running the compiled output in Node.js.
Maybe we have better chances with the Node.js guys to extend the module resolution algorithm.
Expectedly I stumbled upon this when setting a simple Node.js module written in TypeScript and compiled to CommonJS and ES to cater for both cases. I agree with @ericmorand and other similar opinions that, given a valid TypeScript code and valid TS configuration to target ES, the compiler SHOULD generate valid ES code. Otherwise, it should be considered a BUG. If it's a design goal to not generate valid code from TS code, then the design is flawed and needs to be fixed too.
You can now enforce file extensions in imoprts since #44501
You can now enforce file extensions in imoprts since #44501
I tried to use typescript@^4.6.0-dev.20211110and set module: node12 in tsconfig.json but the compiled code still does not include .js file extension. @pwhissell could you give more hints?
@RyanCavanaugh How can emitting Javascript without a compilation error but that doesn't run be anything other than a bug?
If we have to have the .js extension then there should at least be a compilation error if it is missing.
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 whole idea of Typescript it to output valid Javascript code or give me an error if it can't. Currently with this issue the compiler happily generates the code which then fails at runtime. This means that you can't use ESM modules in production. You write some code, it compiles and it then fails at runtime. If I wanted to write unit tests to cover stuff the compiler could be doing I might as well stick to Javascript.
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
I'm not exactly sure what this means but if I set the module compiler option to commonjs the compiler happily translates my imports to require statements. So why it is unacceptable to also translate my import statements for ESM modules?
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.
Indeed, Typescript is a "superset of Javascript". But what means to be a superset? It means:
- you add more features to Javascript,
- you compile those added features to be valid Javascript.
The most basic Typescript additional rule is: "you can type a variable". Like this:
const value: string = "foo"which will be transformed into const value = "foo".
Okay. You add a feature. You compile your code written in your superset language into a valid version of the target language and everything works fine.
Now there is another feature that is added by Typescript: "the file extension is optional when importing ts/js files".
You can write:
import { imported } from "./my-module.js"which is valid Javascript and valid Typescript. That's normal: Typescript is a superset.
But because of this Typescript-specific rule ("the file extension is optional when importing ts/js files") (not a Javascript rule), you can also write (in Typescript only):
import { imported } from "./my-module"which is valid Typescript but not valid Javascript. The proof: it won't execute. Neither by a browser, Node or Deno.
If you add a feature as a superset of a target language, then you have to compile your feature into a valid output of your target language.
And yes, "the file extension is optional when importing ts/js files" is definitely a Typescript-specific feature 😉
I will add that I indeed created a library called tsc-esm as a workaround for this bug, and even though it works quite fine every time I use it (ie 100% of the times I need to create a library written in Typescript) I feel I should not have to patch the output of the Typescript compiler like I do.
I look forward to the day when I can tag my library as "deprecated" :)
at least the imports are also translated to require calls, there is no argument to not translate to correct imports
This whole discussion is absurd. Valid typescript obviously transpiles to invalid ES6 code. I do not understand in which world this can be classified as "works as intended" behavior. Adding ".js" to import statements which actually refer to ".ts" files as workaround is too wild for me. For my current project I have free choice, therefore I'm gonna switch over to CommonJS target module code. CommonJS works without file extensions. In case one can live with CommonJS target module, this is an option to get around this problem.
An alternative way to make this work without adding dependencies is to use Node's --es-module-specifier-resolution=node flag. For example, node --es-module-specifier-resolution=node dist/index.js, where index.js would itself have ES-style imports without the .js file extension.
I've created a pull request wich wich solve this for raltive imports, see:
I've added a compiler switch:
appendModuleExtension
Had the same issue on a big monorepo, can't edit each file manually,
so I wrote a script to fix all esm import and append .js or /index.js
in a safe way: fix-esm-import-paths.js
@silassare I think probably a thousand person, me included, have written similar scripts. This is just absurd.
@ahejlsberg Please help us in the name of practicality and peace of mind.
This conversation is really frustrating. While I can understand not adding the .js suffix under the rationale of not modifying Javascript (though I disagree with it), what I cannot understand is the compiler happily producing code that will fail to run. There should at least be an option to fail compilation if I don't use a .js suffix in the import. I don't even care if it's a default option, as long as it's exposed.
In the meanwhile, what do people recommend doing? What's the safest way to make sure tsc doesn't produce Javascript that will fail in this instance? I'm using node 16 and would really like top level awaits.
Yeah, it's not like there aren't already 1000 compiler options to tune the behaviour of TypeScript, one more won't hurt...
And to reiterate, I'm not asking for am option that rewrites the imports, just an option that makes the compiler say "hey, this probably isn't what you want and will generate broken code", like a fatal warning. There could even be a flag that would override the warning and allow compilation anyways.
So "failOnInvalidModuleImport": true in tsconfig (defaults to false), which would cause the compilation failure, and a flag tsc --allow-invalid-module-importwhich would ignore even if the setting was true, and compile anways.
TypeScript team, can you comment on adding an option like this? This is clearly a problem people have, and I can't see how exposing a default false option to give some greater compile safety could be a bad thing there. It would be a great way to earn some developer good will :)
ETA: @RyanCavanaugh you closed another thread (#16577 (comment)) with the answer that
We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit
I can understand that. But adding an optional check to the compiler to fail compilation if it expects the runtime to fail is an entirely different beast. Are you willing to consider it?
As you all also see in my pull req, the rewrite are only a few lines of code
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.
@adamshaylor for what it's worth, vitest supports .js imports in test code and is largely API-compatible with Jest.
Same confusion 🤔
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
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
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.
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 no, unbelievable
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.
2023 now, and the flicker of hope for this feature is still alive!
See #47436 (comment)
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...
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
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)
Cross-posting this comment which explains that this is, very much intentionally, not something we are going to do.