Typescript: 「インポートパスを「.ts」拡張子で終了することはできません」エラーを抑制しますか？

2つのファイルがあるとします。
a.ts ： import * as b from "./b.ts";
b.ts ： export const b: number = 0;

a.tsをコンパイルするとき、インポート指定子は変更しません。 したがって、出力a.jsには、同じインポート指定子 "./b.ts"が含まれますが、 require("./b.ts")変換される可能性があります。
次に、 a.jsを実行しようとすると失敗します。これは、インポート元のb.tsがなく、 b.jsです。 （または、なし--outDirところb.js隣にあるb.tsそれが輸入を解決します、 b.tsでの解析に失敗、その後、 : number 。 ）

代わりに、インポートからファイル拡張子を省略するか、 .js拡張子を使用する必要があります。

いいえ、ファイルをdenoexecで使用します。コンパイルせずに。

@ 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拡張機能のネイティブな使用をサポートできます。 また、それを実行しようとする可能性もあるので、

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同意し

ライアンのコメントは問題の核心になりますが、すべてのホストを満足させるものを書き出すことができるので、今日の最も一般的な状況であるNode.jsのCJSの方法に制限します。

私はまだ（そして私は以前の問題でこれを言ったと思っていました）、 "moduleResolution": "literal"が缶に書かれていることを実行し、TypeScriptがどんなランタイムホストもそれを理解するだろうと想定できるようにする時間があるかもしれないと思いますモジュール指定子を削除/変更します。

わかりました、しかし：

https://github.com/microsoft/TypeScript/issues/18442
実は2年前のようにコメントしましたが、やはり今でもステージ1の提案です。

https://github.com/microsoft/TypeScript/issues/16577
また、2歳以上で、まだ「議論」の段階にあります。 また、それが進んでいる速度で、すぐには起こりません。

私はここで起こっているタイムスケールから外れ、中期的または長期的な時間枠で起こる可能性に基づいています。

この問題は「質問」としてマークされており、最近の活動は見られません。 ハウスキーピングの目的で自動的に閉鎖されました。 それでも応答を待っている場合は、通常、質問が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のインポートを正しく修正します（エラーが発生しなくなります）。

@danbulantvscode_denoプラグインを使用してもエラーが発生します。

私もDenoを使用していますが、ここでの問題は.tsなく.tsではないと思います。 それは、 tscがエラー番号を無視できるようにする機能に関するものです。 たとえば、 tsc --ignore TS2691ようなものです。

vsコードのDeno拡張機能は素晴らしいですが、問題を解決するのではなく、エディターのエラーを抑制するだけです。 denoとブラウザ用にビルドしたいライブラリがありますが、tscがスローされるため作成できません。

@samuelgozi
私は100％同意します。 これが、サーバー上のnode.jsの代わりとしてDenoをまだ検討していない主な理由です。 Deno用の優れたWebフレームワークはすでに利用可能であり、この美しい夢の邪魔になるのはTYPESCRIPTだけです。

最近これに問題を抱えている人にとっては、アーカイブされているにもかかわらず、 deno_ls_pluginはまさに私が必要とする結果を達成したと言えます。 プラグインを参照するこの問題は、私がプラグインについて見つけた方法です。

私の特定のユースケースは、シンボリックリンクを使用してクライアントとサーバー間でタイプスクリプトコードが共有されている環境で作業していることです。 サーバーはdenoを念頭に置いて作成され、クライアントは通常のtypescriptとphaser3で作成されます。 私が使用しているバンドラーparcelは、 .tsファイルをインポートするtypescriptを処理できます（少なくともparcel-bundler ^1.12.4 ）。 そのため、インテリセンスは修正されません。

deno_ls_plugin 、文字通り.tsモジュールの解像度にパッチを当てるだけなので、私には最適です。 完璧！ つまり、共有コードをインポートし、共有コードをdenoの最前線を念頭に置いて記述し、typescriptクライアント側のインテリセンスにパッチを適用することができます。

手始めに、 yarn add typescript deno_ls_plugin --devコマンドを実行してインストールしました。 インテリセンスが修正されていないことを確認した後、 deno_ls_pluginのreadmeの下部に、ワークスペースバージョンのtypescriptを使用するため

それを行う方法について少し混乱している他の人のために、これが私がしたことです：
まず、開発の依存関係としてdeno_ls_pluginとtypescriptをインストールし、プラグインとしてdeno_ls_pluginを含めるようにtsconfig.jsonを更新しました

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

次に、typescriptファイルをクリックし、右下隅のバージョンをクリックしました。

次に、typescriptバージョンを選択することにしました

ワークスペースのバージョンを選択しました。

私の特定のケースでは、typescript.tsdkも.vscode/settings.jsonが、必要かどうかわかりません。

他の誰かがdenoコードをtypescriptコードと共有しようとしている場合は、シンボリックリンクを使用してサーバーとクライアントの両方のコアコードにリンクし、シンボリックリンク内のコードにその外のdeps.tsファイルをimport_mapはちょっとmeh atmであるため）。

うまくいけば、この小さなメッセージが、古典的なtypescriptプロジェクトとdenoプロジェクトの間でdenoコードを共有しようとして同様の問題を抱えている人に役立つかもしれません。

上記の問題を解決する提案の問題をここで作成しました。 近い将来、それまたは同様の何かを実装するための勢いが得られることを願っています。

この問題を再度開く必要があります。

Deno開発者は、ここで彼らが値する尊敬を得ていません。 彼らはTypeScriptに基づいて素晴らしいランタイムを作成しましたが、TypeScript開発者はそれが正しく機能することを可能にするフラグを追加しません。 この残念な状況はどうしてこんなに長く続くのでしょうか？！

インポートで.ts拡張機能を使用できないと、Denoユーザーに多大な苦痛と問題が発生します。助けてください！

実際にはDeno固有ではありません

拡張機能を明示的に定義する可能性がなければ、多くのJS開発者は問題を抱えることになります

たとえば、 vueプロジェクトでは、常に拡張機能を指定します。そうしないと、次のような状況で問題が発生します。

./component.vue
./component.ts

import component from './component';

なぜこれが閉鎖されているのですか？ 確かに、特にmjsの台頭により、Deno固有ではありません

このスレッドは質問ではなく、機能のリクエストです。 誰かがラベルを修正して再度開くことができますか？ すべてのインポートに// @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にとっての障壁ではありません。

Denoを抑制する隠されたMicrosoft / Node.jsの隠されたカバールはないことを私に信じてください。 TypeScriptコアチーム、Node.jsコミュニティのメンバー、およびDenoコアチームは、定期的に互いに話し合い、協力しています。

@kitsonk

これはDenoにとっての障壁ではありません。

しかし、これはノードとデノという2つの世界の統合に対する障壁です。 拡張子の有無にかかわらずローカルファイルのインポートについて宗教的な意見の相違がある場合、両方のプラットフォームで同時に機能するタイプスクリプトを作成するにはどうすればよいですか。どちらかを選択する必要があります。

拡張子の有無にかかわらずローカルファイルのインポートについて宗教的な意見の相違がある場合、両方のプラットフォームで同時に機能するタイプスクリプトを作成するにはどうすればよいですか。

これはTypeScript / tscでは実際には問題ではありません。 Node.jsはとにかく明示的なモジュールの道を進んでおり、それらがどのように取り組むかは、私が思うにtscのモジュール解決機能に影響を与えます。 Node.jsでESMをより適切にサポートできるようにするために、そこでは継続的な会話があると思います。

この問題が示唆するように行うことは、実際には誰にも役立ちません。 この問題のより良い解決策が＃33437で提案されました。