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

mjbvz commented 6 years ago

From @hooper-hc on September 30, 2018 8:45

when i use

import { PI } from './module.1.ts'

import an module .

vscode linter notice me an error

'The import path cannot end with a ".ts" extension. Consider changing to import “./module.1”。'

hao can i hidden the notice ?

Copied from original issue: Microsoft/vscode#59690

ghost commented 6 years ago

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.

hooper-hc commented 6 years ago

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

zhmushan commented 5 years ago

@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": ["*"]
    }
  }
}

reggi commented 5 years ago

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 :(

zhmushan commented 5 years ago

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

luvies commented 5 years ago

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).

TomasHubelbauer commented 5 years ago

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.

swansontec commented 5 years ago

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.

athyuttamre commented 5 years ago

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.

jpike88 commented 5 years ago

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

kitsonk commented 5 years ago

@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.

jpike88 commented 5 years ago

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.

typescript-bot commented 5 years ago

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.

timburgess commented 5 years ago

Similar issue occurs if you want to directly import an .mjs file e.g. import { forEach } from https://unpkg.com/iterall@1.2.2/index.mjs

VitorLuizC commented 4 years ago

This is closed, but it's not fixed.

ghost commented 4 years ago

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.

slim-hmidi commented 4 years ago

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

samuelgozi commented 4 years ago

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

TicTak21 commented 4 years ago

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

danbulant commented 4 years ago

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,

rpivo commented 4 years ago

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

CreatCodeBuild commented 4 years ago

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.

samuelgozi commented 4 years ago

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.

ghost commented 4 years ago

@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

monoclex commented 4 years ago

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. version Then, I chose to select the typescript version here 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. symlink madness

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.

timreichen commented 4 years ago

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.

timreichen commented 4 years ago

This issue needs to be reopened.

David-Else commented 4 years ago

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!

Hulkmaster commented 4 years ago

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';

zraineri commented 4 years ago

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

David-Else commented 4 years ago

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.

Hulkmaster commented 4 years ago

@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

ghost commented 4 years ago

@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 :)

kitsonk commented 4 years ago

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.

ghost commented 4 years ago

@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

kitsonk commented 4 years ago

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.

FredKSchott commented 3 years ago

TypeScript users on Snowpack are also running into this issue. ESM imports in Snowpack are based on the source filename, so import './file.ts' and import Counter from './counter.tsx' are both expected to work. We ask TS users to use the ".js" file extension as a workaround, but we're looking to add new features that might break this for them entirely.

It feels odd that TypeScript wants to both stay out of import resolution (the right call, imo) but also put arbitrary limits in place. I'm +1 this warning as a default to protect new users from footguns in most projects, but projects like Deno and Snowpack should be able to suppress this.

krasimir commented 3 years ago

The truth for me is that this is a problem of your setup/bundling process. What I did was to remove the extension and configure webpack to resolve .ts files with:

// in webpack.config.js
resolve: {
  extensions: [".json", ".js", ".ts"],
}

VitorLuizC commented 3 years ago

The truth for me is that this is a problem of your setup/bundling process. What I did was to remove the extension and configure webpack to resolve .ts files with:
// in webpack.config.js
resolve: {
  extensions: [".json", ".js", ".ts"],
}

This solves the problem just for webpack. Deno, snowpack, parcel and other tools don't have a way to implement this.

krasimir commented 3 years ago

Interesting @VitorLuizC. How's the webpack transformation happening there. Is it just using the tsc?

Hulkmaster commented 3 years ago

I would also like to mention eslint rule, which greatly explains why explicit extensions are a great thing

https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/extensions.md

tskj commented 3 years ago

Wait, is the current state of things that it is impossible to write a "cross platform" TypeScript library that works in Deno, Node and on the frontend? This really makes me question the maturity of the language.