Typescript: TypescriptエディターでGotoImplementationを有効にする

したがって、定義がアンビエントであるという条件で、この機能が利用可能な場合は対応する.jsにジャンプする必要がありますか？

@RyanCavanaugh @mousetraps @ bowdenk7

したがって、定義がアンビエントであるという条件で、この機能が利用可能な場合は対応する.jsにジャンプする必要がありますか？
はい、これは生産性に非常に役立つシナリオです。 これだけでも非常に価値があります。 アトム-typescriptの作者は、Typescriptコンパイラのフックが増えると、これを実装しやすくなると信じています。 これがjs実装の行番号に関する情報であるかどうかは、typescriptコンパイラが通常内部で知っている情報であるかどうかはわかりません。

さらに、別のシナリオでは、アプリケーションで使用されているライブラリ内の元のtypescript.tsファイル定義へのジャンプを有効にします。 この情報は、d.tsファイルと.jsファイルにプリコンパイルして入手できると思います。 これで、ライブラリのセット全体が、ES5構文jsを出力するソースとして.tsファイルに書き込まれました。 .tsファイルの元のtypescript実装定義にジャンプする機能を実現すると便利です。

ソースマップの使用または元のtsソースへのソース/リンクの配布が必要になる可能性があるため、これが必要なライブラリの.tsファイル実装にジャンプすることをさらに求めていることを認識しています。 関数とクラスの初期ライブラリを生成するtypescriptコンパイラは、実装が行われている行を認識し、ライブラリが何らかの方法で配布されたときに行番号を保持できるため、クラスを使用するアプリケーションのtypscriptコンパイラはライブラリ内のどの行にジャンプするかを知ることができます。

実装関数/クラスの行番号に関するこの情報は、ソースマップで利用できますか？ この情報の他の情報源はありますか？

--allowJSフラグを使用することを考えると、言語サービスはJSファイルを処理できるはずです。

.d.tsファイルと.jsファイルが現在どのように連携しているかはわかりません。 @sheetalkamatはおそらく（間違いなく）私よりもこれについてもっと知っています。

jsファイルへの移動はまだサポートされていないため、再度開きます

これに関する更新はありますか？ typescriptの現在の状態では、多くの著名なライブラリのコードの実装にジャンプすることはできません。

この問題は何度も移動/クローズ/重複/重複排除されており、このバグを修正することで生産性が大幅に向上する可能性があります。

https://github.com/ubershmekel/vscode-ts-goto-sourceには、問題を再現するプロジェクトがあります。 https://github.com/Microsoft/vscode/issues/26325で説明され、 https://github.com/Microsoft/vscode/issuesで参照されています。 / 18321

.d.tsファイルが見つかった場合に引き継ぐように見えるため、javascriptの「定義に移動」を使用するには、ある時点から"typescript.disableAutomaticTypeAcquisition": trueを使用する必要があったことに注意してください。

@DanielRosenwasserこれに関する更新はありますか？ -私にとって最も必要な機能は1つです。

これは、完全にTypescriptで記述されたモノレポで作業する場合に特に厄介です。 タイプにフィールドを追加したり、「定義に移動」を使用した同様の小さな変更を何度も行った後、実際の.tsではなく.d.tsファイルに追加したことに気づきました。 .tsファイル

@DanielRosenwasserこれは進んでいますか？ 私は本当にこの機能が大好きです

同じ問題。 xx.d.tsではなく、ソースコードに「実装に移動」したい

はい、1日に何度も、cmd + clickを使用した後に誤って宣言ファイルを編集し、コードが正しく実行されないと混乱してしまいます。 特にsrcとdecは非常によく似ているので。 宣言のソースに移動するかどうかを選択する方法があれば素晴らしいでしょう。あるいは、ソースに移動する方が常により好ましいIMHO（利用可能な場合）であるため、VSCodeがこれを理解する場合はさらに良いでしょう。

ソースに行くことは常により好ましい私見です（それが利用可能である場合）

ソースがTSにある場合。 ソースがJSにある場合、.d.tsに移動する正当な理由があります

ソースがTSにある場合。 ソースがJSにある場合、.d.tsに移動する正当な理由があります

どうして？ カーソルを合わせると、型の定義が表示されます。 とにかく、型の定義と実装には別々のコマンドが必要です。

これがまだ保留中の理由はありますか？ 回避策、代替案、または何か？ 前もって感謝します

Typescriptパーサーは、多くの場合、.ts実装ファイルからd.tsファイルを生成するためです。 Typescriptエディターが開発者を実装クラスまたは関数のリストに連れて行くことができるように、d.tsファイルと.tsファイルの間のその関連付けを保持できますか（おそらくtypescriptコンパイラオプションで出力されます）？

私は＃21930のブランチを持っており、これらの宣言ファイルのソースマップを正確に作成できます（リクエストに応じて、または＃21930がマージされたら、レビュー用に公開します）。これらのマップをフォローするためのサポートをLSに追加する作業を行っています。 2.8で出荷したいと思います。

そうそう、私たちはそれに取り組んできました。 多くの内部変更が必要でした。 😄

node_modulesの下のフォルダーを手動で展開し、エントリーモジュールファイルを見つけることで実装を見つける際の苦痛を軽減するために、この問題に関する更新を期待してください。

これに対する回避策はありますか？
tsで記述されたdbクエリ用の大きなモジュールがあるので、node_modulesを検索する代わりに、1つのコマンドで実際のソースコードを確認すると非常に便利です。

@ derN3rdコマンドパネルでnode_modulesを参照するためのvscode-search-node-modules拡張機能があります（また、常にREADME vscode-open-node-modules開くフォークもあります）

require / importをクリックしてファイルをオープンソース化するのは完璧なUXにはほど遠いことを理解していますが、 node_modulesスクロールするよりは間違いなく優れています

@ derN3rd 2.9で--declaratrionMapフラグを出荷し（来月中にリリースされる可能性があります）、関連する.d.tsを使用して元のソースTSの定義に移動することをすでに有効にしています。それら（ノードモジュールフォルダー内の宣言ファイルを出荷している場合は、必要なものがたくさん得られる可能性があります）。 また、通常のソースマップもオンになっている場合は、関連するJSとの間でジャンプすることも検討しています。

@weswigham迅速な返信ありがとうございます！ いいですね
機能の準備ができているか、テストの準備ができている場合は、ここに更新を投稿できますか？

--declarationMap （および関連するLSリダイレクト）は、2.8リリースの直後から私たちのナイトリーにありました。 まだ行っていないのはJSファイルのホッピングだけです。これには、追加のエディター調整が必要になる場合があります。

3.0-rcに関するニュースはありますか？

.css .jsonファイルと定義に移動して、 .d.tsファイルに移動します。

import React from 'react'
import Route from 'react-router-dom/Route'
import Switch from 'react-router-dom/Switch'
import Loadable from 'react-loadable'
import  './App.css'
import './tailwind.css'

./App.css定義に

declare module '*.css' {
    const content: any;
    export default content;
}

declare module '*.svg' {
    const content: any;
    export default content;
}

declare module '*.json' {
    const content: any;
    export default content;
}

VSCodeはTypeScript3.0.3に同梱されています。 この問題に関するニュースはありますか？

私のために動作します（VSCode1.27.0を実行しているTS2.9.2で生成された宣言マップ）。 APIコンシューマー（JSで実装）からナビゲートすると、_Go to Definition_により、.tsファイルの実装に移動します。

@robsman _Go to Definition_を使用すると、コンパイルされたjsコードに移動し、_ Go to Type Definition_を使用すると、.d.tsファイルに移動します。

コンパイルしたモジュールをどのように使用/インクルードして、ソースファイルを開きますか？

両方の関数で.d.tsファイルに移動するため、この問題はVSCode1.27.0でもまだ存在します。

編集：私はあなたのコメントを誤解したと思います。 実際のコードに移動しますか？ もしそうなら、monorepoを使用していますか、それともコンパイルされたコードは独自のnpmモジュールで出荷されていますか？ コンパイルしたコードと一緒にソースファイルを出荷しますか？

@ derN3rdが再テストされ、_Go toDefinition_と_Goto Type Definition_、および_Peek Definition_の両方で、_。ts_ファイルの実際のコードが表示されます。

API宣言と実装はどちらも、呼び出し元のパッケージが_git + ssh ..._依存関係と呼ぶ別個のモジュールにあります。

@robsman Go to Definitionは、 .d.tsではなくnode_modules内のソースjsファイル（javascriptの場合）の「this」クラスまたは関数のソースを参照する必要があると思います。 それがSublimeText3で機能するように私は意味します。 とにかく、現在の状態でこの機能がどのVSCodeであるかわかりません

希望はこの問題に優先順位を付けることができます、それは非常に多くのコメントと関連する問題から、それは本当に大きな苦痛です。

コマンドクリックを使用してコードをナビゲートしようとしている人々の長いリストに私を追加してください。 プロジェクトにTSがなく、ナビゲートしているnpmパッケージがTSを使用していませんが、require（ 'co-body'）をコマンドクリックすると、内部で生成されたTS定義に移動します。 私は長年IntelliJユーザーですが、それでも、このため、IntelliJにフォールバックします。

長いリクエストです

私はVSCodeが大好きで、新しいNodeプロジェクトを始めたばかりで、初めてTypeScriptを使用することにしました。 これまでのところほとんどが良好ですが、この問題は問題点でした。 オープンソースで作業する場合、依存関係の実際のソースコードにクリックスルーする機能は、ワークフローに不可欠です。 TypeScriptソースファイルで作業していて、ドキュメントが関連付けられていない@types/xxxモジュールが関連付けられたJSNPMモジュールを使用しています。 TypeScriptを使用したIntelliSenseは優れていますが、常に十分な情報を提供するとは限りません。 少なくとも、 importステートメントからモジュールソースに直接クリックできると便利です。 動作するライブラリもあれば、Passportなどの他のライブラリでは、 @typesモジュールの付属のTypeScriptスタブを通過できないと思います。

これには、_Suggestion_ではなく_Bug_というラベルを付ける必要があります。

コードナビゲーションの欠如は、JavaScript開発者のVSCodeエクスペリエンスを実際に台無しにします。

スレッドをスパムして申し訳ありませんが、 @ promaty私は今のところsearch-node-modules拡張機能を使用してい

WebStormの動作は同じです： StackOverflow 、 BugTracker

• VSCodeには「定義に移動」および「タイプ定義に移動」アクションがあります

• WebStormには、「GoToDeclaration」アクションと「GoToTypeDeclaration」アクションがあります。

ただし、TypeScriptを使用する場合、両方のIDEは同じことを行います。常に型定義に移動してください。

「定義に移動」と「タイプ定義に移動」をnode_modules/ライブラリで使用すると、どちらも.d.tsファイルに移動します。 私は執筆時点で最新のVSCode（1.34.0）を使用しています。

例：npmパッケージ@angular/[email protected] 、 TestBedから@angular/core/testing TestBedをインポートして、 TestBed.createComponentの定義を確認しようとすると、2つの異なるものが得られます。

• 「定義に移動」-> node_modules/@angular/core/testing/src/test_bed_common.d.ts行117
• 「タイプ定義に移動」-> node_modules/@angular/core/testing/src/component_fixture.d.ts 14行目

これは基本的に、AngularソースコードがVSCodeで私から隠されていることを意味します😞それがAngularライブラリの記述方法の症状なのか、TypeScript / VSCodeがソース実装を見つける方法の症状なのかわかりません。

私が知っているのは、自分のコードで「定義に移動」と「タイプ定義に移動」を確実に使用することしかできないということだけです。その場合、ソースに直接移動します。 自分のコードの.d.tsファイルが表示されることはありません。

今のところ、ソースコードを手動で検索する必要があります：/

ああ、Typescript 3.0.1を使用して同じプロジェクトに参加していても、IntellijIDEAがこの関数を本当にうまく機能させていることがわかりました。

この問題の優先順位を上げる必要があると思いました。

+ ,をコマンドしてワークスペース設定を開く必要があります-> Use Ignore Filesチェックを外します-> Search: Exclude: **/node_modules削除し、手動でソースコードを検索します。

毎日！

そのため、 flowは依然として有用です。

typescriptチームの誰かが、コードのどこでこれを修正できる可能性があるかを提案できますか？

面白いことに、一部のパッケージに使用可能なタイプがない場合は、「タイプ定義に移動」の方が実際にうまく機能します。 「移動」機能が好きな場合は、タイピングを使用しない方がよいことを意味します😄

これは、タイピングのないdeviceパッケージの定義に移動できることを示すスクリーンキャストですが、 compressionはランダムなタイピングファイルにつながります。

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh私は他の人に同意する必要があります、これは提案ではなくバグとしてラベル付けする必要があります。

私の場合、自分のコードでこのようなものを定義している場合

const Foo: <T> = () => {
...
}

Tがnpmモジュールからのものである場合、定義に移動しようとすると、2つの定義が表示されます。 私自身のコードとタイピングの定義。 タイプ定義に移動すると、定義ファイルに直接移動します。
最初のケースでは、定義に直接進む必要があります。
これを回避するために、エディター-> goto location：multipleをgotoではなくpeek

この機能が必要です。 どうすればその実装を手伝うことができますか？

+1してください！

2015年以降、解決策はありません:(

OPは、私たちが行くことができるかどうかを尋ねるれた.ts私たちが見つけたときに、ファイル.d.tsあなたが出荷する場合-ファイルを.tsでファイルを.d.tsファイルと宣言--declarationMapsによって生成されたマップ、これが現在の動作です（これでかなり完了です）。 ここで追跡しているこのスレッドの_second_リクエストは、出力.jsファイルに移動するオプションです（たとえば、 .tsソースがない場合に便利です。 t出荷済み）。 実装に関しては、これはすでに公開している宣言ソースマップとjavascriptソースマップを組み合わせるだけの問題ですが、まだ決定していないのは、そのような機能をどのように表示するかです。 tsコードのGo to implementationは、ほとんどのコードですでに有用な意味を持っています（これは定義に行きますが、実装/値の宣言を好みます）...何らかの方法でそれを修正しますか（たとえば、宣言に解決する場合）ファイル、代わりにjsファイルに解決してみてください）、または新しいエンドポイントを追加しますか？ 後者の場合は、vscodeチームとどのようにそれを表面化するかについて話し合う必要があります。

@DanielRosenwasser正直なところ、ここで本当に必要なのは、このようなものをどのように公開したいかについてのより具体的な説明です。これを行うためのツールが用意されています。

vscodeチームのコーダーは、これをどのように実装するかについてのアイデアを提案できます。たとえば、 Go to js implementationなどです。最初の良いステップは、vscode Issue Trackerでチケットを作成し、このチケットを相互参照して、コミュニケーションができるようにすることです。始める。

私の理解では、ここにはいくつかの関連する問題があります。 （1）は大きなものですが、他のことも念頭に置く必要があります。
1）TSタイプがDefinitelyTypedパッケージで宣言されている場合、そのタイプのJSまたはTS実装に移動する簡単な方法はありません。 （または.d.tsが実装と同じ場所に配置されていないその他の場合）
2）選択自体がタイプの場合、[タイプ定義に移動]は機能しません。 「タイプ定義が見つかりません」というエラーが表示されます。
3）タイプ以外の識別子の[定義に移動]の動作に一貫性がありません。 実装に移動する場合もあれば、移動しない場合もあります。 理論的には（1）と同じですが、この矛盾を残したまま（1）を解くことも可能です。

3番目の「移動」メニューオプションを追加せずに、ユーザーが3つの問題すべてを解決する方が簡単だと思います。 代わりに、私の提案は2つのメニュー項目のみを保持し、それらをより一貫して動作させることです。

• Go To Definitionは、ローカルコード、統合された.d.tsファイルを含むnode_modulesパッケージ、またはJSパッケージとは別のDefinitelyTyped定義であるかどうかに関係なく移動する必要があります。
• [タイプ定義に移動]は、選択がタイプ識別子であるか非タイプ識別子であるかに関係なく

3番目の選択肢を必要とする他の一般的なTSユースケースはありますか？

ところで、区別を明確にしたい場合は、「定義に移動」の名前を「実装に移動」に変更できると思いますが、私見では、これはオプションの変更のようです。 一貫性（名前に関係なく）は上位ビットです。

その型がDefinitelyTypedパッケージで宣言されている場合、TS型のJSまたはTS実装に移動する簡単な方法はありません。 （または.d.tsが実装と同じ場所に配置されていないその他の場合）

_技術的に_DTパッケージに合わせていくつかのソースマップを手動でスピンしたい場合は、すでにうまくいく可能性があります。 しかし、ここには自動化されたソリューションは絶対にありません。 私たちが持っている解決策は、TSコンパイラの出力を含むシナリオの改善に基づいています。これらは、ファイル間の正しい関連付けを行うために必要な追加のメタデータを削除できる唯一の場合です。 いくつかのパッケージは今日これをサポートしていると私は信じています-私は先日azurejs sdkを使用していくつかのものをデバッグしていましたが、いくつかの定義に行ってそれらが元のソースにあることを発見したときは嬉しい驚きでした。 そうですね、最新の--declarationMaps出力がバンドルされているTSソースで動作します。

選択自体がタイプの場合、「タイプ定義に移動」は機能しません。 「タイプ定義が見つかりません」というエラーが表示されます。

私はあなたがその問題について新しい問題を開くべきだと思います。 これは、exepections / bug、imoの失敗にすぎません。 最低限、エラーを改善することができます。たとえば、「選択は型のみであるため、その値に関連付けられた型定義はありません」などです。

非型識別子の「定義に移動」の動作に一貫性がありません。 実装に移動する場合もあれば、移動しない場合もあります。 理論的には（1）と同じですが、この矛盾を残したまま（1）を解くことも可能です。

それは_first_定義に行きます。firstはかなり恣意的で、注文ファイルがロードされたようなものに基づいています。 peekウィンドウはすべての定義サイトを表示するので、確かにもっと便利です。 「実装」は機能しません。

ユーザーとして、次のように機能すれば満足します。

Ctrlキーを押しながらシンボルをクリックすると（ほとんどの場合、コードをナビゲートするためにこれのみを使用します）、現在、実装（VS Codeで編集されているパッケージ内にある場合）または宣言（依存関係からのパッケージの場合）のいずれかになります。 。 最初のものは考慮を必要としません。 2つ目は、宣言に移動するときに、Ctrlキーを押しながら宣言をクリックすると、実装が見つかってダウンロードして開くことができる場合は、実装に移動します。 それ以外の場合は、どの問題がソースの検出/オープンを妨げているかというメッセージが表示されます。 それがこのように機能した場合、それは素晴らしいでしょう。

元のソースコードを見つけるには、次のシナリオがあると思います。

1. パッケージは、外部リポジトリのタイプスクリプトと元のソースコードで記述されています。
   a）配布にd.ts jsファイルと
   b）配布には、 d.ts 、 js 、およびtsファイルが含まれます
2. パッケージは、現在のリポジトリ（モノリポジトリの場合）にタイプスクリプトと元のソースコードで記述されており、
   a）配布にはd.tsおよびjsファイルが含まれます
3. パッケージは、外部リポジトリのjavascriptと元のソースコードで記述されています。
   a）ディストリビューションには、独自のd.ts jsファイルと
   a）配布にはjsファイルのみが含まれ、外部の@types定義が使用されます
4. パッケージは、現在のリポジトリ（モノリポジトリの場合）にjavascriptと元のソースコードで記述されています。
   a）配布には、独自のd.ts jsファイルと

1b）-使用されることはめったにありません。bundlephobiaやnpmトレンドなどのリソースは、実行時にそれほど大きくない巨大なパッケージサイズを報告するため、このアプローチは好きではありませんが、人々はこれらのリソースに基づいてサイズを判断します。 したがって、ディストリビューションにtsファイルを含めることをメンテナに依存することはお勧めできませんが、 tsファイルが含まれていれば、問題は解決します。

1a）-（ほとんど？）頻繁なケース。 パッケージは、コンパイル時に元のソースがどこにあったか（microsoft pdbシンボルファイルが宣言するなど）、またはgit + Revision +などからダウンロードできる場所を（package.jsonまたはソースマップを介して）何らかの方法で宣言する必要があります。道。 VSコードは、ローカルファイルに移動するか、 git fetchをローカルキャッシュに移動し、宣言から実装までのナビゲーションで開きます。

2a）-モノレポジトリのケースを自動的に検出できる場合（いくつかのヒューリスティックを使用）、元のCtrl + Clickナビゲーションで実装を直接開くことができます。 不可能な場合は、1a）へのフォールバックで十分です。

私は3についてはあまり気にしませんが、3a）が2番目のCtrl + ClickナビゲーションでJS実装を開くことができればいいのですが。 3b）の場合、 @typesパッケージは、注釈を付けるJSパッケージを宣言する必要があるため、VSコードは、外部パッケージのJS実装に移動するためにこの情報を持つことができます。

私は4についてはもっと気にしませんが、2a）と同じ動作をする可能性があります-4a）のフォールバックは3a）です

それが役に立てば幸い。

1a）-（ほとんど？）頻繁なケース。

ええ、それは私たちが今サポートするためのすべてのツールを持っていると私が言っていることです。 .js.mapファイルと.d.ts.mapファイルを組み合わせて、 .d.tsから.jsへのマッピングを作成できます（中間の.ts ）。 しかし、うーん。 本当に、宣言ファイルに移動してから、もう一度対話して関連するjsに移動したいですか？ jsに直接ジャンプしたくないですか？

「本当に、宣言ファイルに移動してから、もう一度対話して関連するjsに移動したいですか？jsに直接ジャンプしたくないですか？」

1a）の場合、ダブルジャンプでもシングルジャンプでも構いません。 シングルジャンプは「より効率的」と見なすことができますが、ダブルジャンプには、2番目のジャンプが「ライブラリ消費」の観点からブラックボックスへのジャンプであることをユーザーに「思い出させる」という利点があります（つまり、ソースがナビゲート先のファイルは現在のプロジェクトの一部ではありません）。 たぶん、この振る舞いは設定可能にすることができます。

3a）、3b）または4の場合、私は確かにダブルジャンプ

（複数の投稿からの@weswighamと@avkonstへの返信を組み合わせる）

それは最初の定義に行きます。最初の定義はかなり恣意的であり、ファイルがロードされた順序などに基づいています。

特定のインポートされたシンボルの実装に移動する最も一般的なケースでは、なぜ複数の定義があるのでしょうか。 これは一般的な状況ですか？

.d.tsから.jsへのマッピングを生成します（中間の.tsなし）。

「中間TSなし」がわからない。 元の.tsソースが利用可能であっても、VSCodeは変換された.jsに移動するということですか？ それは悪い考えのようです。 元のソースが利用可能な場合、VSCodeは、デバッガーがソースマップを持つトランスパイルされたコードにステップインするときと同じように、そこにナビゲートする必要があります。 とはいえ、パッケージの作成者が悪意のある、または怠惰で、元のTSソースをnpmディストリビューションに含めなかった場合、VSCodeがトランスパイルされたJSにフォールバックし、ユーザーに表示されている理由を説明する警告メッセージを表示するのが妥当と思われます。そのような奇妙で読めないコードと、ユーザーがパッケージの作成者に元のソースをパッケージに含めるように促すこと。

本当に、宣言ファイルに移動してから、もう一度対話して関連するjsに移動したいですか？ jsに直接ジャンプしたくないですか？

2つのステップで付加価値が生まれるとは思いません。 明確で一貫性のあるUXを使用する方がはるかに良いと思います。「タイプ定義に移動」を使用してタイプ定義に移動し、定義に移動（または実装に移動-私たちが選択したもの）を使用して元の定義に移動しますソースコード、または上記のように、元のソースが利用できない場合は、トランスパイルされたJSに。

私見ですが、選択したシンボルが独自のコードで定義されているか、node_modulesで定義されているかによって、動作が異なると、はるかに混乱します。 それは問題ではないはずです。 タイプを確認したい場合は、VSCodeでタイプを確認する必要があります。 実装コードを見たい場合は、VSCodeが私をそこに連れて行ってくれるはずです。 これは特に当てはまります。大規模な組織では、「マイコード」と「ライブラリコード」が常に明るい線であるとは限らないためです。 他の誰かがコードを共有内部パッケージにリファクタリングした場合、そのコードへの移動方法を変更する必要はありません。

私は最初に宣言を確認し、その後（デバッグなどの非常にまれなケースですが）実装を確認したいと思います。

開発者に、型宣言を表示するか、実装コードを表示するかを明示的に（1つのメニュー項目または別のメニュー項目を選択して）選択するように要求する方が明確なようです。 コードの出所によってナビゲーションに一貫性がないことは、不必要に混乱しているように思われます。

>選択自体がタイプの場合、[タイプ定義に移動]は機能しません。
私はあなたがその問題について新しい問題を開くべきだと思います。 これは、exepections / bug、imoの失敗にすぎません。

はい、これは間違いなく最初に修正できます。 私の好みのソリューション（「定義に移動は常に実装に移動する」）が採用された場合、ユーザーは.d.tsを表示したいときにいつでもタイプ定義に移動を使用する習慣があるため、ここに含めました。型に対してこれを行うことが、型以外の識別子に対してどのように機能するかと一貫して機能しなかった場合、奇妙になります。

「最初の定義に行きます。最初の定義はかなり恣意的で、注文ファイルがロードされたようなものに基づいています。」

最初の定義に移動する必要があることについては、返信で言及していません。 Ctrlキーを押しながらシンボルをクリックすると、まず定義に移動し（現在は機能しているため）、その後のCtrlキーを押しながらクリックして実装に移動する必要があると述べました。

「開発者が型宣言を表示するか、実装コードを表示するかを明示的に（1つのメニュー項目または別のメニュー項目を選択して）選択するように要求する方が明確なようです。」

個別のコンテキストメニューを用意することをお勧めします。 これらは、Ctrl + Clickの動作に対して相互に排他的ではありません。

この重大なバグがまだ処理されていないのはなぜだろうか。 タイプスクリプトの採用が増えるにつれ、それはお尻の痛みになりつつあります。

技術的な説明は聞きたくありません。さまざまなユーザーについて多くの説明をした後でも、この問題が認識されない理由を知りたいのです。

@zjamlは、TypeScriptソースファイルまたはJavaScriptソースファイルに移動しますか？ TypeScriptソースファイルがサポートされています。 この問題が現在も開かれているのはJavaScriptソースファイルです。

接線方向に関連しています。 npmに公開されている共通パッケージのモノレポがあります。 このパブリックインターフェイスのため、distはjs + d.tsファイルです。 リポジトリで作業しているとき、VSCodeは常にソースではなくd.tsにジャンプします。 これを回避する方法を知っていますか？

@ 0x80この問題は、今説明したシナリオではまだ開いていると思います。 これを回避できる唯一の方法は、プロジェクトがオープンソースであり、typescriptソースからコンパイルした場合です。 次に、typescriptコンパイラの--declarationMapsフラグをオンにすると、宣言マップをサポートするIDEは、d.tsファイルではなくtypescriptソースに移動します。

これは本当に重要です。 簡単なことをしたい：CTLR +クリックしてnode_modules / library /source.jsまたはsource.tsファイルに移動します。 60個のnode_modules依存関係を持つオープンソースプロジェクト。エクスプローラーでメモ帳を使用するようになりました。

コンポーネントを右クリックすると、「定義に移動」と「タイプ定義に移動」が表示されました。 「素晴らしい、これはうまく設計されている。私の問題の解決策はここにある！」と思いました。 次に、「定義に移動」をクリックして、タイプ定義に移動しました。

これは本当に重要です。 簡単なことをしたい：CTLR +クリックしてnode_modules / library /source.jsまたはsource.tsファイルに移動します。 60個のnode_modules依存関係を持つオープンソースプロジェクト。エクスプローラーでメモ帳を使用するようになりました。

+1
同じ必要性。

敬意を表して、これが実装されていないという事実は信じられないほどです。 そのような基本的な、比較的簡単に
人々の時間を大幅に節約する機能を構築します。

敬意を表して、これが実装されていないという事実は信じられないほどです。 そのような基本的な、比較的簡単に
人々の時間を大幅に節約する機能を構築します。

+1

さて、この機能がまだ利用できない間、node_modules全体を検索する以外にもっと良い回避策はありますか？ 本当に不便です...
たとえば、定義に移動すると、必要なものが実際にnode_modules/@com.abc/sample/src/core/internal/abc.tsにあるときに、 node_modules/@com.abc/sample/lib/core/internal/abc.d.tsになりました。

@ Happin3ss

node_modules全体を検索する以外に、より良い回避策はありますか？

現在のソリューションAFAIKは、宣言マップです。 これらは、.d.tsファイルを対応するTSソースにマップするソースマップです。 依存しているライブラリに宣言マップを実装するように説得できれば（@typesに依存するのではなく、ライブラリパッケージ内に.d.tsを公開する必要があると思います）、クライアントコードから自動的にジャンプできます。元のTS（またはJSでTSコンパイラを使用している場合はJS？）ソースコードに。

私が行っているのは、最も重要な依存関係（少なくとも、TSで作成された依存関係）に対してPRを徐々に提出して、宣言マップを追加するようにすることです。

明らかに、ライブラリを変更する必要がない方がよいでしょう。

別の回避策（ライブラリを変更できない場合）は、ライブラリがパッケージ内に.d.tsをバンドルしているが、宣言マップがない場合に機能します。 その場合は、[定義に移動]を使用して型宣言を取得し、VSCodeの[エクスプローラー]ボタンをクリックしてフォルダーのサイドバーを表示します。 これにより、通常、パッケージのsrcフォルダーに非常に近づくため、すべてのnode_modulesを検索する代わりに、適切なフォルダーを参照して正しいファイルを開くことができます。 これは、明確なファイルの命名などに依存しており、万能薬ではありません。

100％明確にするために、特にライブラリのより良いソリューションを見つけたいと思います。 .d.tsがパッケージとは別に作成されているもの。

見逃したかどうかはわかりませんが、ソース、宣言、宣言マップの実際の最小限の例が何が起こっているのかを理解するのに.d.tsファイル以外に移動するのを見たことがありません。 簡単な例を作成しようとしましたが、機能しません。 .d.ts.mapが隣にあるのに、VS Codeを.d.tsファイル以外に移動させることができません。 私はまた、無視され抱えている他の誰かを見つけました。

@typesような外部タイピングをサポートするのは難しいことは理解できますが、「ハッピーパス」でさえ機能させることができないとはどういう意味ですか？

宣言ファイルを生成するが宣言マップを生成しないライブラリはたくさんあり、それらを有効にするための引数が何であるかは不明です。 このオプションは明確な説明なしに追加されました。少なくとも1つは私が見つけることができます。

はい、宣言マップが問題を解決していないことを確認します。 私のプロジェクトには宣言マップがありますが、vscodeは.d.tsファイルを超えてナビゲートしません。

これが起こったらきっと素晴らしいでしょう。

ms vscode devsの問題の「部屋の中の象」がある場合、これはそれです。

これに関する更新はありますか？
JSからTSに移行するという大きな一歩を踏み出すことにしました。 「何が悪いの？」と思いました。 しかし実際には、それはVSCodeの予期しない動作です

これに関する更新はありますか？
JSからTSに移行するという大きな一歩を踏み出すことにしました。 「何が悪いの？」と思いました。 しかし実際には、それはVSCodeの予期しない動作です

この振る舞いが提起されて以来、長い歴史がありました。 さて、ここでは何も起こっていません。 今のところ計画はありません。
私にとっては、vscodeをそのまま一種のエディターとして使用し続けており、コーディング用のIntellij製品（IDEA）は、あまり好きではありませんが、使用しています。

5年間オープンし、2025年に修正されることを願っています

＃39426で失敗するテストを作成しましたが、実装方法がわかりません

定義を見つけるために毎日地獄を通過するtsdevからのちょうど別の惨めなコメント

これはおかしいです...私はただのTS初心者だと思っていましたが、今私が得ている振る舞いは実際には「標準」であることがわかります???? とてもイライラするので、私が使用した他のすべてのIDE /言語は、最初のリリースでこれが実装されています... :(私はVSコードが大好きですが、正直なところ、これは取引のブレーカーになる可能性があります

Python拡張機能を備えたVSCodeのgo to definition/implementation機能が、ネイティブの組み込みソリューションを備えたJSよりも優れている（少なくとも機能する）理由を誰かが説明できますか？

では、何が起こっているのでしょうか？
cssモジュールにscss.d.tsを使用していますが、scssにジャンプできません。

また、単純な.jsとそれに応じてd.tsを作成する場合、jsに直接ジャンプすることはできません

なぜウェブストームを使用しないのですか？
それはこの問題を解決することができます!!!
私のバージョン2020.1

なぜウェブストームを使用しないのですか？
それはこの問題を解決することができます!!!
私のバージョン2020.1

オープンソースソリューションではなく、無料でもないため

これを修正してください。

この問題は、Microsoftの一部のマネージャーが引き継いだ場合にのみ修正できることは明らかです。この問題は管理および調整する必要があり、マネージャーはワークフローを開発し、コーダーに作業を割り当てます。 ☝
この問題を引き継ぐには経営陣に送る必要があり、経営陣はそれをどのように実施するかを決定します。
したがって、ここにマイクロソフトの有能な誰かがいる場合、彼はショットを与えることができます。 😊