Typescript: Suppressing "The import path cannot end with a '.ts' extension" error?

Suppose you have two files:
a.ts: import * as b from "./b.ts";
b.ts: export const b: number = 0;

When we compile a.ts, we don't change import specifiers. So the output a.js will contain the same import specifier "./b.ts", although possibly translated to require("./b.ts").
Then when you try to run a.js it will fail, because there will be no b.ts to import from, only b.js. (Or without --outDir where b.js is next to b.ts, it will resolve the import to b.ts, then fail parsing at : number.)

Instead, you should omit the file extension from your imports, or use the .js extension.

no，I use deno exec the file 。 without compile。

@hooper-hc
I think we can set tsconfig as a temporary solution like this:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

I'm using deno as well. I found that commenting // @ts-ignore each line of an import works.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Is there anyway to shut this requirement off globally in ts-config?

I also tried @zhmushan's solution and It didn't fix the issue :(

@reggi remove ./
I hope that in the future, we can use a configuration similar to module:deno to simplify the operation.

Would the TypeScript team be open to adding "module": "deno" to the tsconfig? That way we can support using the .ts extension natively, without needing to resort to something like kitsonk/deno_ls_plugin as a workaround. It could also try and enforce it as well, so if you try and do

import module from 'module';

it would show an error like Cannot have an extensionless import with module:deno (the only imports that are allowed are full URLs, and relative imports starting with ./ or ../). A configuration like that could also support natively searching the $DENO_DIR/deps folder for types, since we currently need to use a path setting to workaround that. On top of this, automatic imports could work properly as well, since they currently always do the extensionless import (meaning you have to manually edit it anyway).

This seems like a duplicate of #11901 which was unfortunately closed and silenced. This is important for Deno as was said before and I hope TypeScript will make this extension check configurable or even better remove it altogether.

In most of the Javascript tooling ecosystem, you can do things like import picture from 'image.png', which obviously isn't Javascript. The assumption is that some tool will know how to transpile the referenced file into Javascript so this works correctly. All types of assets and alternative syntaxes, such as JSX, work this way.

Typescript, on the other hand, expects you to either use a blank extension or the .js extension, which is different from how the rest of the ecosystem works. This causes friction for tools like Deno or rollup.js that expect the original file extension.

If tsc wanted to work more like the rest of the world, it could allow .ts as an extension, and then transform that to .js as part of stripping types at build-time. This is obviously a large change to the way the tsc compiler works. On the other hand, there is a wave of alternative tooling based on Babel and Sucrase beginning to enter the ecosystem, so perhaps there is a long-term benefit in aligning with those tools' way to doing things.

Adding my vote here for support for Deno. The current behavior results in TypeScript resolving all types imported in this way to any, which makes developing software for Deno rather difficult.

Deno's a great idea, but trying to convince the TS team to explicitly allow Deno to resolve modules that way to me is a losing battle. It's much easier for Deno just to handle it because (a) way faster to do so, less effort needed and (b) convincing the TS team to rewire its internals like that is a very uphill battle.

If tsc wanted to work more like the rest of the world

TS is becoming increasingly dominant, it's a good strategy to be as compatible as possible to TS conventions including their tooling. Otherwise projects like Deno will never get traction due to the divergence in something as fundamental as module resolution

@jpike88 I disagree. I didn't realise this issue existed. There were a couple other issues semi-related which we were tracking. This issue doesn't say anything about the intent of the team. It is still labelled as a question and it could be argued it really is a duplicate of #16577 or #18442.

Ryan's comment though gets to the heart of the problem, that they can possible write out something that satisfies every host, so they restrict it to the most common situation today, which is Node.js's CJS way.

I still think (and I thought I said this in an issue before) is that there might be time for "moduleResolution": "literal" which would do what it says on the tin, and allow TypeScript to assume that whatever runtime host would figure it out/change the module specifiers.

Ok, but:

https://github.com/microsoft/TypeScript/issues/18442
I actually commented in that like two years ago, and it's still after all this time a stage 1 proposal.

https://github.com/microsoft/TypeScript/issues/16577
Also over two years old, still in the 'discussion' stage. Also at the rate it's going, not happening any time soon.

I'm just going off the timescale things have been happening for here, and basing their likelihood of ever happening in a medium-term or even long-term timeframe off that.

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

Similar issue occurs if you want to directly import an .mjs file
e.g. import { forEach } from https://unpkg.com/[email protected]/index.mjs

This is closed, but it's not fixed.

If anyone here was just looking for a way to be able to run your TypeScript within both the context of Node.js and Deno, know that Webpack + ts-loader will let you keep ".ts" in your imports.

I have this issue whenever I import file from deno? any solution to fix this except adding // @ts-ignore ?

Is this fixed? Importing without extension is not part of the JS anyways, using extensions should not display an error.

I agree with the comments above. It's too bad the problem hasn't been solved yet.
I found an extensions for vscode that should help, but unfortunately it doesn't work properly.
Anyway, I'll leave the links here:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

Following @TicTak21:
The links he mentioned are both deprecated now in favor of the official deno plugin:
https://github.com/denoland/vscode_deno
This extension fixes the .ts and URL imports (so no more errors) correctly,

@danbulant I am still seeing the error using the vscode_deno plugin.

I also use Deno but I think the problem here is not about .ts vs no .ts. It's more about the ability to allow tsc to ignore any error number. For example, something like tsc --ignore TS2691.

The Deno extension for vs code is nice, but it doesn't solve the problem, it just suppresses the error in the editor. I have a library that I want to build for deno and the browser, but I can't because tsc will throw.

@samuelgozi
I agree 100%. This is the main reason why I do not yet consider Deno as a replacement for the node.js on the server. A good web frameworks for Deno is already available, and only TYPESCRIPT stands in the way of this beautiful dream

For anybody having recent troubles with this, I will say that the deno_ls_plugin despite being archived achieved exactly the result I need. This issue that references the plugin is how I found out about it.

My specific use case is that I am working in an environment with typescript code shared between the client and the server using symlinks. The server is written with deno in mind, and the client is written with regular typescript and phaser3. The bundler I am using, parcel, can handle typescript importing .ts files (at least with parcel-bundler ^1.12.4). That leaves the intellisense to be fixed.

deno_ls_plugin works great for me, because it literally just patches .ts module resolution. Perfect! That means I can import the shared code, and have the shared code be written with deno front and foremost in the mind, and patch the intellisense for the typescript client side of things.

For starters, I ran the yarn add typescript deno_ls_plugin --dev command to install it. After seeing that the intellisense wasn't fixed, I noticed some tiny text at the bottom of deno_ls_plugin's readme, to use the workspace version of typescript.

For anyone else a bit confused about how to do that, here's what I did:
First, I installed deno_ls_plugin and typescript as development dependencies, and updated tsconfig.json to include deno_ls_plugin as a plugin

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Then, I clicked on a typescript file and clicked on the version in the bottom right corner.

Then, I chose to select the typescript version

and chose the workspace version.

In my specific case, I have also set typescript.tsdk in .vscode/settings.json but I don't know if I needed to.

If anyone else is also trying to share deno code with typescript code, I used symlinks to link to the core code in both the server and client, and had the code inside the symlink reference a deps.ts file outside of it for dependencies (since import_map is kinda meh atm) so that the typescript version can import the npm package and the deno version can import the URLs.

Hopefully this little message might help anybody having similar issues with trying to share deno code between a classic typescript project and a deno project.

I created a suggestion issue here that would solve the problem above. Hopefully we can get some momentum to have that or something similar implemented in the very near future.

This issue needs to be reopened.

The Deno developers are not getting the respect they deserve here. They made an amazing runtime based on TypeScript, but TypeScript developers won't add a flag to allow it to work properly. How can this sorry situtation go on for so long?!

Not being able to use the .ts extension on imports is causing massive pain and problems for Deno users, please help us!

its not actually Deno specific

without possibility to explicitly define extension many JS devs will have problem

for example in our vue project we always specify extensions, or else we'll have problem in situation like

./component.vue
./component.ts

import component from './component';

Why is this closed? Certainly not Deno specific especially with the rise of mjs

This thread is NOT a question, it is a feature request. Please can someone correct the label and re-open it? Manually adding // @ts-ignore to every import is not an acceptable solution.

@zraineri

I have read several threads dealing with this issue. To summarize, core developers just don't want to do this. They say that it can break other things and that the import algorithm is already quite complex and so on.

Consider me crazy, but it seems to me that there was some corporate solidarity here. The company has spent a lot of money on the node (npm). And doesn't want some upstart to rob them of their profits with her own hands.. So I don't think you can expect much friendliness towards deno from vscode or typescript

Luckily, you can use a plugin that already does more than you ask for and will only get better.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

But the problem is, not only Deno, but also regular js
https://github.com/microsoft/TypeScript/issues/27481#issuecomment-664401169

@Hulkmaster

It looks like we need a shiny new typescript. This one is stuck with its legacy problems and can't (or don't want to) implement imports with extensions. The deno team seems to be planning to write their own typescript (in rust, I suppose :)

I am part of the Deno core team. I agree that the TypeScript compiler shouldn't get involved in rewriting module specifiers. The internals of Deno suppress this diagnostic message and the vscode plugin for Deno also supresses this message. This isn't a barrier for Deno.

Trust me that there isn't some hidden Microsoft/Node.js hidden cabal suppressing Deno. The TypeScript core team, member of the Node.js community and the Deno core team regularly talk to each other and collaborate.

@kitsonk

This isn't a barrier for Deno.

but this is a barrier to the unification of two worlds: Node and Deno. How can I write a typescript that will work on both platforms at the same time if you guys have religious disagreements about importing local files with or without extensions.. I'll have to choose a side

How can I write a typescript that will work on both platforms at the same time if you guys have religious disagreements about importing local files with or without extensions.

That really isn't an issue with TypeScript/tsc. Node.js is headed the way of explicit modules anyways, and how they tackle that will have an impact on the module resolution capabilities of tsc I would suspect. I believe there are continued conversations there, to be able to better support ESM in Node.js.

Doing as this issue suggests would not really help anyone. A better solution to the problem was proposed in #33437.