生成された出力でbrowserifyやwebpackなどの他のバンドルツールを使用していますか？ または、これがノード上で直接実行されることを期待していますか？

この動作が意図されている場合、パスマップを使用してノードと組み合わせてrelative-import-hellを解決するにはどうすればよいですか？

コンテキストを追加するために、 "paths"は、Node.js require()とは異なり、再マッピングを可能にするローダーで使用するように設計されています。 意図された動作は、TypeScriptがさまざまなローダーによって使用されるさまざまなモジュールIDのタイプ情報を解決できるようにすることであり、モジュールIDを書き換えることではありません。 基本的に、それはあなたが思ったことをしません。 また、私の意見では、ローダーの解決戦略を反映する機能のみを備えている必要があります。

@mhegazyノードと直接連携することを期待していました。 バックエンドアプリケーション用です。 @kitsonkは、これが意図したとおりに機能しており、typescriptがモジュールパスを書き換えないことを示していますか？

はい、これは意図されていました-モジュール（ユーザーによって作成されたもの）が実行時に解決できるが、コンパイラーによって検出されなかった場合の実行時と設計時のエクスペリエンスの不一致を軽減することです。 この時点で、コンパイラーは常にユーザーが提供したモジュールIDが正しいと想定し、それを変更しようとはしません。

同様の応答https://github.com/Microsoft/TypeScript/issues/9910#issuecomment-234729007

了解、ありがとう。 より多くの人々が混乱するのを防ぐために、これをよりよく文書化することが役立つかもしれません。 現在、 https：//www.npmjs.com/package/module-aliasを使用してノードで動作させています。

TSの立場を評価し、ノードを使用している私たちの90％のユースケースに対する簡単な解決策を示しますが、 baseUrl相対的なrequire()呼び出しを大騒ぎせずに使用できる便利さを求めています。

このソリューションは、ノードのrequire()呼び出しをフックし、「main」のdirnameを使用してリクエストを解決してbaseUrlを模倣します。 したがって、 baseUrlコンパイラオプションも、ソース「main.ts」が配置されていたのと同じディレクトリに設定されていると想定しています。

使用するには、この小さなコードのチャンクを「main.ts」の上部に貼り付けます。

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

mika-fischerが言及したmodule-aliasパッケージを使用する場合、パッケージに登録するパスは/で終わるべきではなく、パスはパスに相対的であることに注意してください。ここで、 package.jsonは（明らかかもしれませんが、明確にするのは良いことです）、

したがって、tsconfigファイルにこれがある場合：

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

これをpackage.jsonに登録する必要があります：

"_moduleAliases": {
  "foo": "dist"
}

コンテキストを追加するために、「パス」は、Node.js require（）とは異なり、再マッピングを可能にするローダーで使用するように設計されています。 意図された動作は、TypeScriptがさまざまなローダーによって使用されるさまざまなモジュールIDのタイプ情報を解決できるようにすることであり、モジュールIDを書き換えることではありません。 基本的に、それはあなたが思ったことをしません。 また、私の意見では、ローダーの解決戦略を反映する機能のみを備えている必要があります。

大きなプロジェクトでセットアップしようとして時間を無駄にした後、ここに来ました。
この動作がほとんど変わらない場合は、この問題を閉じる前にドキュメントを更新することをお勧めします。
公式ドキュメントhttps://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping％20docsには、「再マッピングを可能にするローダー」を使用する必要があることについては何も記載されていません。

プロジェクトフォルダに「tspath」をインストールして実行します... https： //www.npmjs.com/package/tspath

@ef-carbon/tspm

また、「momothepug/tsmodule-alias」を試してパス解決をエイリアスすることもできます。

https://www.npmjs.com/package/@momothepug/tsmodule -alias

https://www.npmjs.com/package/module-aliasだけが私のために働いた...

私もこれをmodule-aliasで機能させることができましたが、tsconfig.jsonとpackage.jsonの両方でエイリアスを追跡する必要があるという欠点がありました。 誰かがもっと簡単な解決策を見つけましたか？

@mattyclarksonが指摘した解決策も機能しますが、ts-nodeと並べて使用する方法が見つかりませんでした。 何か案は？

https://github.com/momoThePug/tsmodule-aliasをご覧ください

2018-05-31 15:04 GMT-05：00 [email protected] ：

私もこれをモジュールエイリアスで動作させることができましたが、欠点があります
tsconfig.jsonとの両方でエイリアスを追跡する必要があること
package.json。 誰かがもっと簡単な解決策を見つけましたか？

@mattyclarksonによって指摘された解決策
https://github.com/mattyclarksonも機能しますが、方法が見つかりませんでした
ts-nodeと並べて使用します。 何か案は？

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
。

@DanyelMoralesに感謝します、これは本当に便利です。

どういたしまして！ :)

2018-05-31 16:35 GMT-05：00 [email protected] ：

ありがとう@DanyelMoraleshttps ://github.com/DanyelMorales 、これは本当に
ハンディ。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
。

放出されたパス名が実際に正しくない場合、誰かがこの機能のポイントを教えてもらえますか？ つまり、TypeScriptコンパイラがそれに満足しているが、最終結果が実行可能でない場合、この機能のユースケースは何ですか？

モジュールではないもの、つまりインポートではないものに対して、どのように相対パスマッピングを行う必要がありますか？

以前行っていたソースファイルに関連する特定のディレクトリを読み取るノードスクリプトでは、次のようになります。

const starterDir = path.resolve(__dirname, './templates/starter')

typescriptはスクリプトをコンパイルし、（configに基づいて）別のディレクトリに書き込むため、__dirnameは上記のパスの解決につながりません。 これに対する解決策は何でしょうか？

モジュールではないもの、つまりインポートではないものに対して、どのように相対パスマッピングを行う必要がありますか？

それは本当に「Node.jsとTypeScriptの質問をどのように使用するか」であり、Gitter.imまたはStackOverflowではるかによく尋ねられます。

私はTypeScriptが大好きですが、これは狂気です。

わかりません。 TSコードベースについてほとんど知らなくても、これを実装するのは難しいことではありません。 クライアントとサーバーで共有プロジェクトを使い始めたばかりです...なぜTSは最初にパス機能を提示し、それから実際にそれを使用するためにフープを飛び越えさせるのですか？ なぜTSは、私が作成するすべてのプロジェクトでバンドラー/ローダーを使用したいと想定するのですか？ 私はTSを使用してプロジェクトを簡素化しようとしていますが、90％実装されたTS機能を補うためにツールライブラリを増やすのではありません。

仰るとおりです。 TSはフロントエンド用に開発されたと思います。
すでにtsエイリアスパスを非常にうまく実装しており、Requirejsでは
同じこと。 しかし、Nodejsプロジェクトの場合、それは非常に困難です。 :(

El jue。、9月20日 de 2018 02：50、Josh [email protected]
escribió：

わかりません。 TSコードベースについてほとんど知らなくても、これは
実装するのは難しいことではありません。 共有プロジェクトを使い始めたばかりです
クライアントとサーバーで...なぜTSはパス機能を
そもそも、実際にそれを使用するためにフープを飛び越えさせますか？ どうして
TSは、すべてのプロジェクトでバンドラー/ローダーを使用したいと想定していますか？
作る？ TSを使用してプロジェクトを簡素化しようとしていますが、それ以上の作業はしていません。
90％実装されたTS機能を補うためのツールライブラリ。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
。

+1！

webpackは、パスマップ（またはbabel-plugin-module-resolverなどの他のツール）を解決するのに役立つ場合がありますが、宣言（ .d.ts ）は解決できません。

宣言内のすべてのパスが解決されるわけではありません。

この問題にも遭遇しました。 放出されたコードにパスマッピングが含まれることは論理的であるように思われました。 モジュールエイリアスに頼る。 ただし、Typescriptの+1は、オプションでこの機能を提供します。

これはコンパイラオプションとして追加するだけではありませんか？ 明らかにそれは人気のあるリクエストです。 コンパイラの動作について何も知らないので、それを実装するのは非常に簡単ではありませんか？ TypeScriptコンパイラで直接簡単に解決できるのに、なぜ他の場所でフープをジャンプするように強制するのでしょうか。

+1

ts-transformer-importsとttypescriptを使用して、絶対パスベースのTypeScriptインポートを相対Javascriptファイルにコンパイルできます。

tscを引き続き使用できるコンパイル時ソリューションを作成しました。 https://github.com/joonhocho/tscpaths

Microsoft / TypeScript＃15479（コメント）

import {foo} from "@/some/folder/foo"がたくさんあり、出力されたd.tsファイルがエイリアスを解決しないd.tsファイルをvue-cliで出力しようとすると、この問題が発生しました。

このスレッドや他のスレッドを一般的に検索して調べると、ニージャークの反応は「これはTSが解決する問題ではない」ように見えますが、カスタムパスエイリアス（完全に有効で複雑なプロジェクトに推奨されるアプローチ）（カスタムのサードパーティビルドプロセスなしで）d.tsファイルの生成を使用することはできないため、typescriptコンパイラは宣言ファイルプロセスでもこれらのエイリアスを解決する必要があります。

コンパイラの仕事は、typescriptファイルの有効なjavascriptおよびd.tsファイルを出力することであり、この有効なシナリオでは機能しません（tsconfigファイルのパスエイリアスを使用）。

私はこの問題について少し混乱しています。 閉じられ、「意図したとおりに機能する」というラベルが付けられています。 Typescriptが無効なソースを出力することを意図していることを理解していますか？ 奇妙に思えます。

乞食は選択者にはなれませんが、Typescriptを使用すると、バニラJSの多くの苛立たしい側面を回避でき、相対的なインポート（'../../../../../utils/parser'）をその1つとして数えます。 Typescriptがこれらをクリーンアップできたら素晴らしいでしょう！

@codeitcodyそれのようです。 サードパーティのパッケージがないと機能しないものを出力するのは馬鹿げていますが、それが現実です。

さて、これは陥るのに良い問題ではありません。

フープを飛び越えずにアプリを本質的に使用できなくする機能があることは非常に逆効果のようです（つまり、問題を回避するためにより多くの依存関係をインストールします）。

この問題は2年前からあり、実装されるかどうかについての公式の言葉はありません。

これが必要であり、Node.jsプロジェクトでTypeScriptの最高の機能の1つを使用するための基本的な機能を考えると、それがどのように扱われるかはかなりひどいものです。

@mhegazyあなたや他の誰かが、2年後の今、TypeScriptチームがこれをもう一度見て、再考する可能性があるかどうかを知らせてくれませんか？

webpackは、パスマップ（またはbabel-plugin-module-resolverなどの他のツール）を解決するのに役立つ場合がありますが、宣言（ .d.ts ）は解決できません。

宣言内のすべてのパスが解決されるわけではありません。

これを達成する方法はありますか？ カスタムReactコンポーネントライブラリがあり、エイリアスにpathsを使用しようとすると、このエラーが発生しました。 ロールアップ付きの2つのバンドルと、 --emitDeclarationOnly付きのタイプを実行します

モジュールエイリアスは使用できません。次のようになっているためです。

警告：このモジュールは、デフォルトのrequire動作を変更するため、他のnpmモジュールでは使用しないでください。

Redditでこの投稿に賛成するのを手伝ってください： https ：//www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
ここでこの巨大な議論が必要な理由がわかりません。 このバグは簡単に解決できるはずです。 tsconfigのオプションと誰もが、彼が現在の動作（何らかの理由で）なのか、それとも実用的なアプローチなのかを決めることができます。

Dropboxでも同じ問題が発生し、このトランスフォーマーをオープンソース化しましたhttps://github.com/dropbox/ts-transform-import-path-rewrite

同じ経験を何度も経験しました。パスエイリアスが解決されることを期待していますが、module-aliasをインストールし、package.jsonを更新して、メインファイルにインポートする必要があることを忘れています。 これがTypescriptによるコンパイルステップで処理された場合は素晴らしいでしょう。

痛い。 これはTypeScriptにとって大きな打撃です。 これの意味はどこにありますか？

psコメントするだけではいけません+1

クラブ@def14ntへようこそ。 私たちは夢想家の幸せなグループであり、より良い未来を見つめながら、TypeScriptが私たちの生活を楽にするシンプルで賢明なコンパイラオプションを実装する日を辛抱強く待っています。 その日がついに私たちに迫ったとき、彼らが新しく見つけた翼で夕日に堂々と飛び去るとき、豚のかっこいいピンク色の体がないか空をチェックしてください。

笑、TypeScriptチームがサポートを追加できるもののnpm拡張機能をインストールします。 たぶん、彼らはますます多くの拡張機能を追加するのをやめ、この基本的な機能を追加する必要があります。

@mika-フィッシャー
https://www.npmjs.com/package/module-aliasを使用して、eslintが「未解決のパス」@ root / bla / bla（JSファイル内）について警告するようにするにはどうすればよいですか？ そして、WebStormとVS Codeでそのようなパスのオートコンプリートを有効にする方法は？

私の場合、インポートの自動完了は、TypescriptプロジェクトのデフォルトでVSCodeで機能します。

@bobmoffはい、TSファイルからTSファイルをインポートするのにすべてが良いようです。
ただし、TSファイルからの `require（'@ root / bla / bla'）のオートコンプリートとナビゲーションは機能しません。

JSプロジェクトをTSに変換したいので、jsファイルの名前を1つずつtsに変更できると思いました。
これは非常に難しく、tsでもIDEでもサポートされていないことに気付きました。すべてのjsファイルの名前を一度にtsに変更する必要があります。

1つのJSファイルの名前をTSに変更すると、 buildディレクトリ内のすべての相対パスが壊れたためです（おそらく「allowJs：true」を使用する必要がありますが、2ギガバイトのJSファイルを含むプロジェクトが1つあります。それらをビルドディレクトリにコンパイルするのは奇妙です％））。
わかりました。モジュールエイリアスでこれを解決しようとすると、IDEのナビゲーションとオートコンプリートが機能しなくなり、eslintは約100500の「未解決のパス」を警告します。 私はすでにTSが少し嫌いです。大規模なJSプロジェクトへの移行は、TSマーケティング担当者が言うほど簡単ではないようです。 JSバックエンドプロジェクトのgolangへの移行はもっと簡単なようです:)

回避策としてtscpathsを正常に使用しています。

私も。 私は本当にtscpathsをお勧めします。 想定どおりに動作します。

私の簡単な回避策：

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

またはpm2process.ymlを使用

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

これに偶然出くわしただけで、TypeScriptがお尻に本当に苦痛を与えることがあります。

なぜこのスレッドが何度も繰り返されるのか、私は真剣に理解していません。
私たちは皆、「パス地獄」について知っています、そしてあなたは（エイリアスを使用することによって）できることを知っています
本当にきれい
その混乱まで、このスレッドの誰もがこれを知っています！

エイリアスはTypeScriptコンパイラによって解釈され、正確にコンパイルされます
当然のことながら、
結果として得られるjavascriptをいじくり回してはいけません。
使いたい
エイリアスは自分で解決する必要があります！

....またはApple、Google、Microsoftでスレッドを開始します
JavaScriptエンジンに機能を実装して、
彼らはできます
エイリアスをインターペットする;-)

TypeScriptコンパイラは、本来の機能を正確に実行します。

Angularの世界で作業している場合は、道路が舗装されています。
あなたを実行します
ノードで直接コードを作成するには、パスを解決するためのツールが必要です。
製
あなただけのためのそのようなツール、それは1年以上の間生産で使用されました、
それは
ここスウェーデン最大の新聞で使われているので、
裸になる
ノードの骨、私はここで何も売ろうとはしていません、私はお金を稼いでいません
これから ：）

はい、「tsmodule-alias」や同様のハックなどのツールがあります。
実際にそれを機能させる
あなたが非常に注意しているが、それが混乱している場合は、を使用して回避策があります
ts-ノード、
シェルスクリプトなど...yaddayadda

やっと十分だと感じたので、自分を閉じ込めて作りました
TsPath
コンパイル時のエイリアス

> npm install -g tspatj

myproject> tsc

myproject> tspath

また

myproject> tspath --f

ヘッドレス（ビルドサーバーで非常に便利であることが証明されています）

これで完了です。JavaScriptファイルには
正しい相対パス、それは私たちがここで望んでいることではありませんか？

乾杯！ :)

https://www.npmjs.com/package/tspath

Densön1月13日。 2019 kl 22:20 skrev Fabio Spampinato <
[email protected]>：

これに偶然出くわしただけで、TypeScriptが本当に苦痛になることがあります
お尻。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
。

@duffman

エイリアスはTypeScriptコンパイラによって解釈され、正確にコンパイルされます
当然のことながら、結果として得られるjavascriptをいじくり回してはいけません。
エイリアスを使用したい場合は、これを自分で解決する必要があります。

まったくそう思わない。 あなたが冗談を言っていない限り、私は本当に言うことができませんでした。

TypeScriptは、ネイティブコンパイラに部分的にしか実装されていないジョブを完了するために、サードパーティのツールを必要とせずに_動作する_コードをコンパイルする必要があります。

TypeScriptコンパイラは、本来の機能を正確に実行します。

このスレッドがtscも縮小化などを行うように要求する人々でいっぱいだった場合、私はあなたに同意します。 しかし、そうではありません。 コンパイラが実行可能コードを生成するように要求するのは人々です。 コンパイラーに聞くのはそんなに多くないと思いますよね？

また、次のような機能を使用しない場合は、実行可能コードが生成されます。
JavaScriptエンジンでサポートされていないので、それは非常に理にかなっているはずです
たとえば、アプリケーションがC ++コンパイラのせいになりますか？
ダイナミックリンクライブラリを使用し、プログラムがマシン上で実行されないこと
これらがインストールされていませんか？

これは、相対パスを管理する場合に利用できる機能です。
AngularがWebPackで行うように、または私が行うように、それらの責任を負います
TSPathを使用したすべてのTypeScriptプロジェクト！

作業環境の設定方法がわからない場合は、使用しないでください。
私はこれがここでのマイクロソフトの責任だとは本当に思いません、彼らは
機能を提供し、それがどのように機能するかを次に示します。
それはあなたが望むように、またはそれが機能することを期待するように機能しないかもしれませんが、それはしません
それは間違っています！

また、私は興味があります、あなたはこれがあなたを邪魔させているのですか？
TypeScriptを使用して開発していますか？

Denmån1月14日。 2019 kl 21:34 skrev Robert [email protected] ：

TypeScriptコンパイラは、本来の機能を正確に実行します。

このスレッドがtscも行うことを要求する人々でいっぱいだった場合
縮小化など、私はあなたに同意します。 しかし、そうではありません。 これは
コンパイラが実行可能コードを生成することを要求する人々。 私は本当に
コンパイラーに聞くのは多すぎるとは思いませんか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
。

これは、相対パスを管理し、AngularがWebPackで行うように、またはTSPathを使用するすべてのTypeScriptプロジェクトで行うように、相対パスを管理する場合に利用できる機能です。

これは、コンパイラが壊れたコードを出力する機能です。これらのパスを適切に解決するために1行のコードを記述しただけで機能する可能性のあるコードです。

出力されたコードを実行できるようにするためだけにTSが外部バンドラーを必要とするという事実は、明らかにばかげています。

また、次のような機能を使用しない場合は、実行可能コードが生成されます。
JavaScriptエンジンでサポートされていない、

TypeScriptはJavaScriptにコンパイルされることになっていることを私はいつも理解していました。 特定の機能がJavaScriptエンジンでサポートされていないことを私に言っているのなら、なぜそれらが正確にそこにあるのですか？

アプリケーションのダイナミックリンクライブラリがインストールされていないマシンでプログラムが実行されない場合、C ++コンパイラのせいになりますか？

いいえ。ただし、コンパイラのエラーや警告なしに、実際には存在しなかった他のC++コードにリンクできる場合は責任を負います。

あなたは本当にこれを理解していませんね？ それがあれば、コードは壊れていません
壊れたのは、コンパイラを構成したためです
この場合、「プラットフォーム」がサポートしていないコードを生成するには、
エイリアス！

あなたの場合、エイリアスを使用しないでください。「あなた」はエイリアスを真剣にサポートしていません。

これが1行の修正であっても（もちろんそうではありません）、
コンパイラが何をすべきか、そして
すべきではありません！ この機能は、ローダーをサポートしないために追加されました。
逆に、読んでください
公式ドキュメントのパスマッピングについては、繰り返しになりますが、これを使用しています
違う！

繰り返しますが、この機能はローダー/リゾルバー用です、あなたはそれがどのように誤解されていますか
動作するので、いいえ、マイクロソフト
コンパイラを変更して、エイリアスなしでエイリアスを貼り付けることができるようにする必要があります
それをサポートする環境！

デンティス1月15日。 2019 kl 04:41 skrev Fabio Spampinato <
[email protected]>：

これは、相対パスを管理する場合に利用できる機能です。
AngularがWebPackで行うように、または私が行うように、それらの責任を負います
TSPathを使用したすべてのTypeScriptプロジェクト！

これは、コンパイラが壊れたコードを出力するようにする機能です。
それらを解決するために1行のコードしか記述していなければ機能している可能性があります
パス。

TSが出力されたコードのためだけに外部バンドラーを必要とするという事実
実行できるのはばかげている。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
。

ローダーがパスマッピングを使用するため、それらが存在します。それがサポートされている理由です。
そして、あなたは（私のように）ローダーなしでそれらを使用することを主張しているので、
の問題
機能を利用できるようにツールを使用していますか？

デンティス1月15日。 2019 kl 05:10 skrev Robert [email protected] ：

また、次のような機能を使用しない場合は、実行可能コードが生成されます。
JavaScriptエンジンでサポートされていない、

私はTypeScriptがコンパイルすることになっていることを常に理解していました
JavaScript。 特定の機能がによってサポートされていないことを私に言っている場合
では、JavaScriptエンジンは、なぜ正確に存在するのでしょうか。

アプリケーションの動的リンクの場合、C++コンパイラのせいにしますか
ライブラリと、プログラムがマシン上で実行されないことは、これらを持っていません
インストールされていますか？

いいえ。ただし、リンクしなかった他のC++コードにリンクできる場合は責任を負います。
実際には、コンパイラのエラーや警告なしで存在します。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
。

ほら、あなたの主張がわかります。 私がやります。 しかし、コンパイラーの仕事の一部は、最後にもう一度健全性チェックを行うことです。 せいぜいコンパイルしても実行されないコードは一貫性のない動作であり、この問題を最初に読んだとき、ドキュメントは明らかにそこにない動作を示唆しているようでした

ドキュメントのそのセクションを教えてください。

1月15日。 2019kl。 05:31 skrev Robert [email protected] ：

ほら、あなたの主張がわかります。 私がやります。 しかし、コンパイラの仕事の一部は正気を保つことです
最後にもう一度確認してください。 せいぜいコンパイルしても実行されないコードは
一貫性のない動作と私がこの問題を最初に読んだとき
ドキュメントは明らかにそこにない行動を示唆しているようでした

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
。

この機能は、ローダーをサポートしないために追加されました。
逆に、読んでください
公式ドキュメントのパスマッピングについては、繰り返しになりますが、これを使用しています
違う！

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffmanここの人々がこの機能を望んでいるのがわかりませんか？ あなたは、この「機能」がどのように使われるべきかを理解するのは愚かだとみんなに言っています。 OK-あなたはこれをそのように見ることができますが、誰が知っていますか-多分それは逆です...

ちなみに、私の意見は次のとおりです。

エイリアスはコンパイラに組み込まれているため、エイリアスを使用したプロジェクトのコンパイルは問題ありません。 それはユーザーにそれが示唆しているように機能すると思わせるかもしれません（そしてこの問題は私が正しいことのかなり良い証拠です）。 それは非論理的でさえあるようです-なぜ「公式」エディターで何かが機能するのですか（vscode-特に「自動インポート」機能を使用する場合、vscodeはエイリアスパスを使用します）、結果のコードが機能しないのになぜcopilerも正常に機能するのですか？ 「jsエンジンはそれをサポートしていません」と言うと、私はさらに質問したくなります-TSはJSの「問題」のいくつかを軽減するためのものではありませんでしたか？

私はこれの2つの解決策のうちの1つを期待します：
1）エイリアスでインポートを正しくオーバーライドする
2）警告を表示する

「正しい振る舞い」と言うのは間違っていると思います。 そうではありません。 TSはアセンブリ言語ではなく、C /C++でもありません。

開発チームは、エイリアス解決のサポートを追加する必要があります。 追加することをお勧めします
tsconfigのコンパイラ解決用のキー。

それはいいマイクロソフトだろう!!!!!!

お願いします。エイリアスを使用してアプリケーションを改善するには、あなたの助けが必要です。

:(ここのみんなはの遅れのために悲しくて怒っています（そして空腹です）
一貫性。 Typescriptは素晴らしいです、私はそれが大好きです...

私達はそれが大好き！

ホームレスの開発者よろしく...

El mar。、15deene。 de 2019 08:02、 MikeS.notifications @github.com
escribió：

ちなみに、私の意見は次のとおりです。

エイリアスはコンパイラに組み込まれており、コンパイルは問題ありません。 それはユーザーを作るかもしれません
彼らが考えるようにそれが機能するはずだと思う（そしてこの問題はかなりです
それが本当であることの良い証拠）。 それは非論理的なようです-なぜ何かがうまくいくのか
「公式」エディター（vscode-特に「自動インポート」機能を使用する場合、
vscodeはエイリアスパスを使用します）、コードを生成するときにcopilerも正常に機能する理由
動かない？ 「jsエンジンはそれをサポートしていません」と言うと私は聞きたくなります
さらに-TSは、JSの「問題」の一部を軽減するためのものではありませんでしたか？

私はこれの2つの解決策のうちの1つを期待します：

1. エイリアスでインポートを正しくオーバーライドする
2. 警告を表示する

「正しい振る舞い」と言うのは間違っていると思います。 そうではありません。 TSはそうではありません
アセンブリ言語であり、C /C++でさえありません。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
。

。 TSはアセンブリ言語ではなく、C /C++でもありません。

TSがC++ではないことを証明することによって、あなたが何を指摘しようとしているのか、私は本当に理解していません。私たちのほとんどは、私が思うことをよく知っています。

また、エイリアス/パスマッピングが世界中の本番環境で使用されていることも確認しました。当然、VS Codeはそれをサポートする必要がありますが、MSがセットアップに合わせてコンパイラーを作成することはまだ議論の余地がありません。

私が理解するのに苦労しているのは、なぜあなたがそれを維持するのかということです。コンパイラはそれが機能するはずのように機能します。もう一度、機能が何のためにあるのかを明確に述べているドキュメントを読んでください！

つまり、2分程度でパスエイリアスを使用して動作するTS開発環境をセットアップできます。WebPackを使用したくない場合は、TSPathを使用してすべてのjsファイルのすべてのパスを1秒で解決し、パッケージに追加できます。実行スクリプトとしての.jsonであり、それについて考える必要はありません。問題は存在せず、コンパイラーは本来の機能を維持し、幸せな万歳を続けることができます！？

または、実際のコンパイラがこれを行うことが非常に重要である場合は、コンパイラをフォークして自分で実装することをお勧めします。大ヒットになるか、セットアップされてから人々が満足している可能性があります。エイリアスをサポートするための環境。

TypeScriptの上位5人の貢献者を召喚します： @ahejlsberg @ andy-ms @DanielRosenwasser @sandersn @sheetalkamat

TypeScriptチームはこの問題を再考できますか？ このスレッドは、両方の観点でいくつかの有用な議論を提供していると思います。最近の人気と経過した時間の長さを考えると、もう一度見直す必要があります。

この問題の状況により、TSをタイプチェッカーの義務のみに降格する以外に選択肢はありませんでした。
BabelはTS構文を適切にサポートするようになり、 babel-plugin-module-resolverとともに、このユースケースで機能するコードを適切に出力することができます。
唯一の欠点は、BabelがTS構成を気にしないため、構成のビットをtsconfig.jsonから複製することです。 しかし、それはノードプロジェクトで絶対パスを操作するための許容可能な価格であり、ボーナスとして、私はバベルマクロのような素晴らしいものでエコシステム全体を手に入れます。

これは、 tscコンパイラの代わりにドロップインとして機能するようになった最小のセットアップです。

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• package.json ：
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• tsconfig.json ：

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• .babelrc ：

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

絶対パスでtypescriptを使用したいのですが、webpackやbabelなどを構成する必要があるようです。この単純な機能を実現するのは難しいので、もっと簡単なはずです😞

私はこの問題を認めます、私はこの特定のことに気づいていたかどうかわかりません
私自身の個人的な設定による問題、または多分私は:)それはスーパーではありません
重い修正、修正は単に（盲目的に）distPathを信頼することです、
これは実際には現在のソリューションよりも単純なコードではありません。
明日までに修正を利用できるようにしてください...

Denmån1月28日。 2019 kl 15:59 skrev0099伟伟[email protected] ：

絶対パスでtypescriptを使用したいのですが、
config webpackやbabelか何か、達成するのは難しすぎる!!!

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
。

pathsの現在の動作に関する実際の文書化されたユースケースがこのスレッドで言及されていないため、これをここに残します。 @types/パッケージは、semverに関して機能をバックポートしません。 ただし、使用できる古いAPIの更新されたタイプが含まれています。 たとえば、 history@3が最新の場合、$ history@2を使用しています。

"paths": {
    "history": [ "history/v2" ]
}

コンパイラには、タイプエイリアスと「コード」エイリアスを区別するための追加オプションが必要になります。 パスエイリアスを実際に発行するように動作を変更する場合は、正しい型のバージョンを見つける機能をコンパイラに追加する必要があります。

これは、提案された動作に反対する議論ではありません。 むしろ、型のバージョン管理のためのエイリアスとjust™作業ソリューションを発行したいと思います。 これを変更することが、人々が思っているほど簡単ではないかもしれない理由を説明したかっただけです。

全社的なTSワークショップで2回目、私はこの非常識で恥ずかしい行動を説明しなければなりませんでした...

真剣に！

どのような言語コンパイラ、特にJavaScriptの正確性を主な売り込みとするコンパイラは、壊れたコードを「機能」として生成しますか？！？！

コメントに不満を感じて申し訳ありませんが、ここでのコミュニティの見解は無視され、繰り返し軽視されているようです。

これが何回参照されているかを見てください...非常に多くの人々にとって、時間と注意の無駄です。

私はあなたの欲求不満を理解していますが、行動が正しいと感じている多くの人々は、それが正しいことを意味するわけではありません。

TypeScript書き換えモジュール識別子は、滑りやすい滑りやすい坂道です。 このスレッドで何度も表現されているのは、TypeScriptは、他のモジュールリゾルバーや他のビルドツールの動作をモデル化するように構成可能であり、それらを置き換えたり実装したりしないことです。

TypeScriptが柔軟な方法でモジュールを解決するように構成できるからといって、TypeScriptが「壊れたコード」を発行することを意味するわけではありません。 この構成をミラーリングする特定のローダーとバンドラーは問題なく機能します。

私たちが何かに批判的である場合、オプションのドキュメントはそれが放出を変更しないことを明らかにしていますが、それが修正することを意図していなかった問題を修正するように見えるかもしれない何かをオプションに命名したことでチームを非難することができます。

特定のツールが問題を解決しないので、それがツールの故障であるとは限らない。 問題を解決するために必要なすべてのツールを持っていないだけかもしれません。

@kitsonkあなたが今言ったことはすべてマークから外れています。

問題は、TSが開発/テスト中に一方向に動作し、コンパイルが完了した後に別の方向に動作することです。

TSがモジュールリゾルバーになりたい場合は、パターンを選択してそれに固執する必要があります。 ts-nodeで何かを実行すると、TSをコンパイルしてnodeで実行した場合とまったく同じように動作するはずです。

そうではなく、それが問題です。

たぶん、モジュールマップは将来の欲求不満を軽減するでしょう。 しかし、ここでの私たちの立場と解決したい技術的な問題はかなり明確です-パスマッピングは外部解決スキームの動作を反映しています（たとえば、AMDとSystem.jsのパスマッピング、Webpackや他のバンドラーのエイリアス）。 それは私たちがあなたの道を変えることを意味するものではありません。

最近の議論は建設的なものではないと思いますし、ここで将来の変更も予測していないので、この問題をロックします。