Typescript: 抑制“导入路径不能以'.ts'扩展名结尾”错误？

假设您有两个文件：
a.ts ： import * as b from "./b.ts";
b.ts ： export const b: number = 0;

编译a.ts ，我们不会更改import指示符。 因此，输出a.js将包含相同的导入说明符“ ./b.ts”，尽管可能会转换为require("./b.ts") 。
然后，当您尝试运行a.js ，它将失败，因为将没有b.ts可以从中导入，只有b.js可以导入。 （或者在没有--outDir下，其中b.js在b.ts旁边，它将把导入解析为b.ts ，然后在: number解析失败。 ）

相反，您应该从导入中省略文件扩展名，或使用.js扩展名。

不，我使用deno exec文件。不进行编译。

@ hooper-hc
我认为我们可以将tsconfig为这样的临时解决方案：

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

我也在使用deno。 我发现在导入的每一行中注释// @ts-ignore都是可行的。

// @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'

无论如何，在ts-config中全局关闭此要求？

我也尝试了@zhmushan的解决方案，但没有解决问题:(

@reggi删除./
我希望将来我们可以使用类似于module:deno来简化操作。

TypeScript团队是否愿意向tsconfig添加"module": "deno" ？ 这样，我们可以支持本地使用.ts扩展名，而无需求助于kitsonk / deno_ls_plugin之类的解决方法。 它还可以尝试并强制执行它，所以如果您尝试执行

import module from 'module';

它会显示类似Cannot have an extensionless import with module:deno的错误（允许的唯一导入是完整URL，以及以./或../开头的相对导入）。 这样的配置还可以支持在$DENO_DIR/deps文件夹中本地搜索类型，因为我们当前需要使用路径设置来解决该问题。 最重要的是，自动导入也可以正常工作，因为它们当前始终执行无扩展名导入（这意味着您仍然必须手动对其进行编辑）。

这似乎是＃11901的副本，但不幸的是关闭并保持了沉默。 如前所述，这对于Deno非常重要，我希望TypeScript可以使此扩展名检查可配置，甚至更好地将其完全删除。

在大多数Javascript工具生态系统中，您可以执行import picture from 'image.png'类的事情，这显然不是Javascript。 假设某些工具会知道如何将引用的文件转换为Javascript，这样就可以正常工作。 所有类型的资产和替代语法（例如JSX）都可以这种方式工作。

另一方面，Typescript希望您使用空白扩展名或.js扩展名，这与生态系统其余部分的工作方式不同。 这会导致诸如Deno或rollup.js之类的需要原始文件扩展名的工具产生摩擦。

如果tsc希望更像世界其他地方那样工作，则可以允许.ts作为扩展，然后在构建时将其转换为.js作为剥离类型的一部分。 显然，这是对tsc编译器工作方式的重大更改。 另一方面，基于Babel和Sucrase的替代工具浪潮开始进入生态系统，因此与这些工具的处事方式保持一致可能会带来长期利益。

在这里对支持Deno表示支持。 当前行为导致TypeScript将以这种方式导入的所有类型解析为any ，这使得为Deno开发软件相当困难。

Deno是个好主意，但试图说服TS团队明确允许Deno以这种方式解析模块对我来说是一场失败的战斗。 对于Deno来说，处理它要容易得多，因为（a）这样做的速度更快，所需的精力更少，并且（b）说服TS团队重新内部布线，这是一场艰巨的战斗。

如果tsc想像世界其他地方一样工作

TS越来越占主导地位，这是一个与TS约定（包括其工具）尽可能兼容的好策略。 否则，诸如Deno之类的项目将永远不会因为模块分辨率等根本问题的分歧而受到关注

@ jpike88我不同意。 我没有意识到这个问题的存在。 我们正在跟踪其他一些半相关的问题。 这个问题没有说明团队的意图。 它仍然被标记为一个问题，可以说它确实是＃16577或＃18442的重复。

Ryan的评论虽然成为问题的核心，但他们可以写出满足每台主机的东西，因此将其限制在当今最常见的情况下，这就是Node.js的CJS方式。

我仍然认为（并且我以前曾在一个问题中说过这一点）是可能会有"moduleResolution": "literal"时间来完成它在锡罐上所说的操作，并允许TypeScript假定任何运行时主机都可以理解它退出/更改模块说明符。

好的但是：

https://github.com/microsoft/TypeScript/issues/18442
我实际上像两年前那样发表了评论，毕竟这仍然是第一阶段的提案。

https://github.com/microsoft/TypeScript/issues/16577
也是两年多了，还处于“讨论”阶段。 而且以它的速度发展，很快就不会发生。

我只是偏离了这里发生的事情的时间表，并根据它们在中期乃至长期的时间框架内发生的可能性。

该问题被标记为“问题”，并且最近没有活动。 它已自动关闭以进行家政服务。 如果您仍在等待响应，那么问题通常更适合stackoverflow 。

如果您想直接导入.mjs文件，则会发生类似的问题
例如import { forEach } from https://unpkg.com/[email protected]/index.mjs

这是关闭的，但不是固定的。

如果这里有人只是想在Node.js和Deno上下文中都能运行TypeScript的方法，请知道Webpack + ts-loader将使您在导入文件中保留“ .ts”。

每当我从deno导入文件时都会遇到此问题？ 除了添加// @ts-ignore之外，任何解决此问题的解决方案？

这是固定的吗？ 无论如何，不​​带扩展名的导入都不是JS的一部分，使用扩展名应该不会显示错误。

我同意以上评论。 太糟糕了，问题尚未解决。
我发现了vscode的扩展应该会有所帮助，但不幸的是，它无法正常工作。
无论如何，我将在此处保留链接：
1）https://github.com/justjavac/vscode-deno
2） https://github.com/axetroy/vscode-deno

在@ TicTak21之后：
现在不推荐使用他提到的链接，而推荐使用官方deno插件：
https://github.com/denoland/vscode_deno
此扩展程序可以正确修复.ts和URL导入（因此不会再出现错误），

@danbulant我仍然使用vscode_deno插件看到错误。

我也使用Deno，但我认为这里的问题不是.ts vs没有.ts 。 这与允许tsc忽略任何错误号的能力有关。 例如，类似tsc --ignore TS2691 。

vs代码的Deno扩展很好，但是并不能解决问题，只是抑制了编辑器中的错误。 我有一个要为deno和浏览器构建的库，但是我不能，因为tsc会抛出异常。

@samuelgozi
我同意100％。 这是为什么我还不考虑Deno替代服务器上的node.js的主要原因。 一个适合Deno的好的Web框架已经可用，只有TYPESCRIPT阻碍了这个美丽的梦想

对于最近对此有麻烦的任何人，我都会说deno_ls_plugin尽管已存档，但完全达到了我需要的结果。 引用插件的问题是我如何发现的。

我的特定用例是，我正在使用符号链接在客户端和服务器之间共享打字稿代码的环境中工作。 服务器是用deno编写的，而客户端是用常规打字稿和phaser3编写的。 我正在使用的捆绑程序parcel可以处理输入.ts文件的打字稿（至少使用parcel-bundler ^1.12.4 ）。 这就使智能感知得以解决。

deno_ls_plugin对我来说很棒，因为它实际上只是修补了.ts模块分辨率。 完善！ 这意味着我可以导入共享代码，并使共享代码以deno开头和最重要的思想编写，并为打字稿客户端方面的智能感知打补丁。

首先，我运行yarn add typescript deno_ls_plugin --dev命令进行安装。 看到智能感知未解决后，我注意到deno_ls_plugin自述文件底部的一些小文本使用了typescript的工作区版本。

对于其他对如何执行此操作感到困惑的人，这是我所做的：
首先，我安装了deno_ls_plugin和typescript作为开发依赖项，并更新了tsconfig.json以包括deno_ls_plugin作为插件

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

然后，我单击一个打字稿文件，然后单击右下角的版本。

然后，我选择选择打字稿版本

并选择工作区版本。

在我的特定情况下，我还在.vscode/settings.json设置了typescript.tsdk，但我不知道是否需要这样做。

如果其他任何人也在尝试与打字稿代码共享deno代码，则我使用了符号链接来链接到服务器和客户端中的核心代码，并让符号链接中的代码在其中引用了deps.ts文件以用于依赖项（因为import_map有点类似atm），以便打字稿版本可以导入npm包，而deno版本可以导入URL。

希望这个小消息可以帮助任何有类似问题的人尝试在经典打字稿项目和Deno项目之间共享Deno代码。

我在这里创建了一个建议问题，可以解决上述问题。 希望我们能在不久的将来有所发展。

此问题需要重新打开。

Deno开发人员在这里没有得到应有的尊重。 他们基于TypeScript实现了惊人的运行时，但是TypeScript开发人员不会添加标志使其正常工作。 这种遗憾的情景怎么会持续这么长时间？

无法在进口商品上使用.ts扩展名，这给Deno用户造成了巨大的痛苦和问题，请帮助我们！

它实际上不是特定于Deno的

没有明确定义扩展的可能性，许多JS开发人员都会遇到问题

例如在我们的vue项目中，我们总是指定扩展名，否则在以下情况下会出现问题

./component.vue
./component.ts

import component from './component';

为什么关闭？ 当然不是Deno特有的，尤其是随着mjs的兴起

该线程不是问题，它是功能请求。 请有人可以更正标签并重新打开它吗？ 手动将// @ts-ignore到每个导入都是不可接受的解决方案。

@zraineri

我已经阅读了处理此问题的多个线程。 总而言之，核心开发人员只是不想这样做。 他们说它可以破坏其他事物，并且导入算法已经相当复杂，依此类推。

让我发疯，但是在我看来，这里有些公司团结。 该公司在节点（npm）上花费了很多钱。 并且不想让一些新贵用自己的双手抢走他们的利润。.因此，我认为您不会期望从vscode或Typescript获得对deno的极大友好

幸运的是，您可以使用一个已经完成了超出您要求的功能并且只会变得更好的插件。
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

但是问题是，不仅是Deno，而且还有常规js
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@浩克大师

看来我们需要一个闪亮的新打字稿。 这是一个遗留问题，无法（或不想）通过扩展实现导入。 deno团队似乎正在计划编写自己的打字稿（我想是生锈的：）

我是Deno核心团队的一员。 我同意TypeScript编译器不应参与重写模块说明符。 Deno的内部抑制了该诊断消息，并且Deno的vscode插件也禁止了该消息。 这不是Deno的障碍。

相信我，没有任何隐藏的Microsoft / Node.js隐藏的阴谋压制Deno。 TypeScript核心团队，Node.js社区的成员和Deno核心团队定期相互交谈并进行协作。

@kitsonk

这不是Deno的障碍。

但这是两个世界统一的障碍：Node和Deno。 如果你们在导入带有或不带有扩展名的本地文件方面存在宗教分歧，我该如何写一个可以同时在两个平台上使用的打字稿。

如果你们在导入带有或不带有扩展名的本地文件方面存在宗教分歧，我该如何写一个可以同时在两个平台上使用的打字稿。

TypeScript / tsc确实不是问题。 无论如何，Node.js都是显式模块的发展方向，它们如何解决将对我怀疑的tsc模块解析能力产生影响。 我相信那里会有持续的对话，以便能够更好地支持Node.js中的ESM。

按照这个问题的建议做，并不会真正帮助任何人。 ＃33437中提出了对该问题的更好解决方案。