Typescript: Aktivieren Sie Go to Implementation in Typescript Editors

Sie möchten also, dass diese Funktionalität zum entsprechenden .js springt, sofern verfügbar, vorausgesetzt, die Definition ist ambient, richtig?

@RyanCavanaugh @mausfallen @bowdenk7

Sie möchten also, dass diese Funktionalität zu den entsprechenden .js springt, sofern verfügbar, vorausgesetzt, die Definition ist ambient, richtig?
Ja, dies ist ein Szenario, das für die Produktivität sehr nützlich wäre. Dies allein wäre sehr wertvoll. Ich glaube, der Autor von Atom-Typescript glaubt, dass mehr Hooks im Typescript-Compiler ihm die Implementierung erleichtern würden. Ich bin mir nicht sicher, ob dies Informationen zu den Zeilennummern der js-Implementierung sind, die der Typoskript-Compiler normalerweise intern kennt.

Darüber hinaus wäre ein weiteres Szenario ein Sprung zur ursprünglichen Typoskript-.ts-Dateidefinition in der von der Anwendung verwendeten Bibliothek möglich. Ich könnte mir vorstellen, dass diese Informationen vorkompiliert in d.ts- und .js-Dateien verfügbar sind. Wir haben jetzt ganze Sätze von Bibliotheken, die in .ts-Dateien als Quelle geschrieben werden, die die ES5-Syntax js ausgibt. Es wäre schön, die Möglichkeit zu erreichen, zur ursprünglichen Typoskript-Implementierungsdefinition in den .ts-Dateien zu springen.

Ich bin mir bewusst, dass dies noch mehr erfordert, zur Implementierung der .ts-Datei in der erforderlichen Bibliothek zu springen, da möglicherweise die Verwendung der Quellzuordnung oder die Verteilung der Quelle / des Links zur ursprünglichen ts-Quelle erforderlich ist. Es scheint mir, dass der Typscript-Compiler, der die anfängliche Bibliothek von Funktionen und Klassen generiert, die Zeilen kennt, in denen sich die Implementierung befindet, und die Zeilennummern beibehalten könnte, wenn die Bibliothek irgendwie verteilt wird, so dass der Typscript-Compiler der Anwendung, die die Klasse verwendet, könnte wissen, zu welcher Zeile in der Bibliothek zu springen.

Sind diese Informationen zur Zeilennummer der implementierenden Funktion/Klasse in Quellzuordnungen verfügbar? Gibt es andere Quellen für diese Informationen?

Da wir das Flag --allowJS verwenden werden, sollte der Sprachdienst mit den JS-Dateien arbeiten können.

Ich weiß nicht, wie .d.ts Dateien und .js Dateien derzeit in dieser Hinsicht zusammenarbeiten. @sheetalkamat weiß wahrscheinlich (definitiv) mehr darüber als ich.

Erneutes Öffnen, da das Aufrufen von js-Dateien noch nicht unterstützt wird

Irgendwelche Updates zu diesem? Der aktuelle Stand der Typoskription ist, dass Sie in vielen bekannten Bibliotheken nicht zur Implementierung von Code springen können.

Dieses Problem wurde mehrmals verschoben/geschlossen/dupliziert/dedupliziert und die Behebung dieses Fehlers könnte eine enorme Produktivitätssteigerung bedeuten.

https://github.com/ubershmekel/vscode-ts-goto-source hat ein Projekt, das das Problem reproduziert. Wie in https://github.com/Microsoft/vscode/issues/26325 erklärt und in https://github.com/Microsoft/vscode/issues/10806 und https://github.com/Microsoft/vscode/issues referenziert

Beachten Sie, dass ich "typescript.disableAutomaticTypeAcquisition": true von einem Punkt aus verwenden musste, um das Javascript "zur Definition gehen" zu verwenden, da es so aussieht, als würden die .d.ts Dateien übernehmen, wenn sie gefunden werden.

@DanielRosenwasser Irgendwelche Updates dazu? - Einziges meistgesuchtes Feature für mich.

Dies ist besonders ärgerlich, wenn Sie in einem Monorepo arbeiten, das vollständig in Typescript geschrieben ist. Ich habe beim Hinzufügen eines Felds zu einem Typ oder ähnlichen kleineren Änderungen mehrmals "Gehe zur Definition" verwendet, es hinzugefügt und später festgestellt, dass es wieder fehlt, und erkannte, dass ich es der Datei .d.ts hinzugefügt habe und nicht dem tatsächlichen .ts Datei

@DanielRosenwasser Geht das voran? Ich würde mich sehr über diese Funktion freuen

gleicher Fehler. Möchten Sie "Zur Implementierung" zum Quellcode, nicht zu xx.d.ts

Ja, mehrmals täglich bearbeite ich versehentlich die Deklarationsdatei, nachdem ich cmd + click verwendet habe, und bin verwirrt, wenn der Code nicht richtig ausgeführt wird. Zumal src und dec sehr ähnlich aussehen. Wäre großartig, wenn es eine Möglichkeit gäbe, zu wählen, ob ich zur Quelle der Deklaration gehen möchte, oder noch besser, wenn VSCode dies herausfinden würde, da der Weg zur Quelle IMHO immer vorzuziehen ist (wenn sie verfügbar ist).

zur Quelle zu gehen ist IMHO immer vorzuziehen (wenn sie verfügbar ist)

Wenn die Quelle in TS ist. Wenn die Quelle jedoch in JS ist, gibt es einen guten Grund, zur .d.ts zu gehen

Wenn die Quelle in TS ist. Wenn die Quelle jedoch in JS ist, gibt es einen guten Grund, zur .d.ts zu gehen

Wieso den? Ich kann einfach mit der Maus darüber fahren, um die Typdefinition zu sehen. Auf jeden Fall sollte es einen separaten Befehl für die Typdefinition und die Implementierung geben.

Gibt es einen Grund, warum dies noch aussteht? Abhilfe, Alternative oder so? Danke im Voraus

Da der Typescript-Parser oft die d.ts-Dateien aus den .ts-Implementierungsdateien generiert. Könnte diese Verbindung zwischen den d.ts- und .ts-Dateien beibehalten werden (vielleicht mit einer Typoskript-Compileroption ausgegeben), damit Typoskript-Editoren Entwickler zu einer Liste der implementierenden Klassen oder Funktionen führen können?

Ich habe einen Zweig von #21930, der es ermöglicht, genau diese Deklarationsdatei-Sourcemaps zu erstellen (und werde diese entweder auf Anfrage oder nach dem Zusammenführen von #21930 zur Überprüfung herausgeben) und arbeite daran, Unterstützung in unserem LS hinzuzufügen, um diese Maps zu verfolgen. Wir wollen es in 2.8 versenden.

Also ja, wir haben daran gearbeitet. Es brauchte nur viele interne Änderungen. 😄

Erwarten Sie Aktualisierungen zu diesem Problem, um das Auffinden von Implementierungen durch manuelles Erweitern von Ordnern unter node_modules und Lokalisieren der Eintragsmoduldatei zu erleichtern.

Gibt es dafür einen Workaround?
Da wir ein großes Modul für unsere db-Abfragen in ts geschrieben haben, wäre es wirklich schön, den echten Quellcode mit einem Befehl zu sehen, anstatt die node_modules zu durchsuchen.

@derN3rd Es gibt eine vscode-search-node-modules Erweiterung zum Durchsuchen von node_modules im Befehlsfeld (und ich habe auch einen Fork, der immer README vscode-open-node-modules öffnet)

Ich verstehe, dass es bei weitem nicht der perfekte Ux ist, auf „Require/Import“ zu klicken und eine Datei als Open Source zu öffnen, aber definitiv besser als node_modules scrollen

@derN3rd wir werden in 2.9 ein --declaratrionMap Flag ausliefern (das im Laufe des nächsten Monats veröffentlicht werden könnte), und wir haben bereits aktiviert, auf Definitionen im ursprünglichen Quell-TS über ein zugehöriges .d.ts mit sie (die, wenn Sie Deklarationsdateien in Ihrem Knotenmodule-Ordner versenden, möglicherweise eine Menge von dem erhalten, was Sie wollen). Wir prüfen auch das Springen zu/von dem zugehörigen JS, vorausgesetzt, normale Sourcemaps sind ebenfalls aktiviert.

@weswigham danke für die schnelle Antwort! Hört sich gut an
Könnten Sie hier ein Update veröffentlichen, wenn die Funktion bereit ist oder getestet werden kann?

--declarationMap (und die damit verbundene LS-Umleitung) ist seit der Veröffentlichung von 2.8 in unseren Nachtblättern. Das einzige, was wir noch nicht gemacht haben, ist das JS-Datei-Hopping, da dies möglicherweise eine zusätzliche Editor-Koordination erfordert.

Gibt es dazu Neuigkeiten zu 3.0-rc?

Gleiches Problem mit .css und .json Dateien. Gehen Sie zu Definition , um zur Datei .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'

Gehe zu Definition auf ./App.css bringt mich zu

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

VS Code wird jetzt mit TypeScript 3.0.3 ausgeliefert. Gibt es Neuigkeiten zu diesem Thema?

Funktioniert bei mir (mit TS 2.9.2 generierte Deklarationszuordnungen, auf denen VSCode 1.27.0 ausgeführt wird). Wenn ich von einem API-Consumer (implementiert in JS) _Go to Definition_ navigiere, komme ich zur Implementierung in der .ts-Datei.

@robsman _Go to Definition_ sollte Sie zum kompilierten js-Code führen, während _Go to Type Definition_ Sie zur .d.ts-Datei führen sollte.

Wie verwenden/einschließen Sie Ihr kompiliertes Modul, um die Quelldateien zu öffnen?

Dieses Problem besteht bei mir immer noch in VSCode 1.27.0, da beide Funktionen mich zur .d.ts-Datei führen

EDIT: Ich glaube, ich habe deinen Kommentar falsch verstanden. Bringt es Sie zum echten Code? Wenn ja, verwenden Sie ein Monorepo oder wird Ihr kompilierter Code in einem eigenen npm-Modul ausgeliefert? Liefern Sie die Quelldateien mit Ihrem kompilierten Code?

@derN3rd erneut getestet, sowohl _Go to Definition_ und _Go to Type Definition_ als auch _Peek Definition_ bringen mich zum echten Code in der _.ts_-Datei.

Die API-Deklaration und -Implementierung befinden sich beide in einem separaten Modul, das vom aufrufenden Paket als _git+ssh..._-Abhängigkeit bezeichnet wird.

@robsman Ich denke, Go to Definition sollte mich auf die Quelle "dieser" Klasse oder Funktion in der Quell-Js-Datei (wenn es Javascript ist) innerhalb von node_modules nicht .d.ts verweisen. Wie es in Sublime Text 3 funktioniert, meine ich. Jedenfalls verstehe ich nicht, wofür VSCode diese Funktion im aktuellen Zustand hat

Hope kann dieses Problem priorisieren, es ist wirklich ein großer Schmerz, von so vielen Kommentaren und verwandten Problemen.

Bitte fügen Sie mich der langen Liste von Leuten hinzu, die versuchen, mit Befehlsklick durch den Code zu navigieren. Ich habe kein TS in meinem Projekt und das npm-Paket, zu dem ich navigiere, verwendet kein TS, aber ein Befehlsklick auf require('co-body') führt mich zu einer intern generierten TS-Definition. Ich bin schon lange IntelliJ-Anwender und greife deshalb immer noch auf IntelliJ zurück.

es ist eine lange anfrage

Ich mag VS Code sehr und habe gerade ein neues Node-Projekt gestartet und mich entschieden, zum ersten Mal TypeScript zu verwenden. So weit, so meistens gut, aber dieses Problem war ein Schmerzpunkt. Bei der Arbeit in Open Source ist die Möglichkeit, sich in Abhängigkeiten zu echtem Quellcode durchzuklicken, für den Arbeitsfluss von entscheidender Bedeutung. Ich arbeite in TypeScript-Quelldateien und verwende JS NPM-Module mit zugehörigen @types/xxx Modulen, die keine zugehörige Dokumentation haben. IntelliSense mit TypeScript ist großartig, liefert aber nicht immer genügend Informationen. Zumindest wäre es schön, von der import Anweisung direkt zur Modulquelle klicken zu können. Ich glaube, bei einigen Bibliotheken, die funktionieren, und bei anderen, zB Passport, komme ich nicht an den zusätzlichen TypeScript-Stubs im @types Modul vorbei.

Dies sollte als _Bug_ bezeichnet werden, nicht als _Suggestion_.

Der Mangel an Code-Navigation ruiniert wirklich die VSCode-Erfahrung für JavaScript-Entwickler.

Entschuldigung, dass ich den Thread @promaty Ich benutze die search-node-modules- Erweiterung 😬 vorerst

WebStorm hat das gleiche Verhalten: StackOverflow , BugTracker

• VSCode hat die Aktionen "Gehe zu Definition" und "Gehe zu Typdefinition"

• WebStorm hat die Aktionen "Gehe zu Deklaration" und "Gehe zu Typ-Deklaration"

Aber wenn Sie TypeScript verwenden, machen beide IDEs dasselbe: Gehen Sie immer zur Typdefinition!

"Gehe zu Definition" und "Gehe zu Typdefinition", wenn sie in node_modules/ Bibliotheken verwendet werden, führen mich beide zu .d.ts Dateien. Ich bin auf dem neuesten VS-Code zum Schreiben (1.34.0).

Zum Beispiel: npm package @angular/[email protected] , wenn ich TestBed aus @angular/core/testing importiere und versuche, die Definition von TestBed.createComponent , erhalte ich zwei verschiedene Dinge:

• "Gehe zu Definition" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts Zeile 117
• "Gehe zu Typdefinition" -> node_modules/@angular/core/testing/src/component_fixture.d.ts Zeile 14

Dies bedeutet im Grunde, dass der Angular-Quellcode in VS Code vor mir verborgen ist 😞 Ich bin mir nicht sicher, ob dies ein Symptom dafür ist, wie die Angular-Bibliothek geschrieben ist oder wie TypeScript/VS-Code Quellimplementierungen findet.

Ich weiß nur, dass ich "Go to Definition" und "Go to Type Definition" nur zuverlässig in meinem eigenen Code verwenden kann. In diesem Fall werde ich direkt zur Quelle geleitet; Mir wird nie eine .d.ts Datei für meinen eigenen Code angezeigt.

Wir müssen jetzt manuell nach Quellcodes suchen :/

Aw, ich habe gerade herausgefunden, dass Intellij IDEA diese Funktion irgendwie wirklich gut funktioniert, selbst wenn ich am selben Projekt arbeite und Typescript 3.0.1 verwende

Ich dachte, die Priorität dieses Themas sollte erhöht werden.

Wir müssen + , befehlen, um die Arbeitsbereichseinstellungen zu öffnen -> Use Ignore Files deaktivieren -> Search: Exclude: **/node_modules löschen und Quellcodes manuell suchen.

JEDEN TAG!

Deshalb ist flow immer noch nützlich.

Könnte jemand vom Typoskript-Team vorschlagen, wo im Code dies möglicherweise behoben werden kann?

Eine lustige Sache ist, dass, wenn ein Paket keine Typen zur Verfügung hat, "Gehe zu Typdefinition" dafür besser funktioniert. Das bedeutet, dass es besser ist, keine Eingaben zu verwenden, wenn Sie die Funktionen "Gehe zu" mögen 😄

Hier ist ein Screencast, der zeigt, dass ich zur Definition von device Paketen gehen kann, die keine Eingaben haben, aber compression führt mich zu einer zufälligen Eingabedatei:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh Ich muss anderen Leuten zustimmen, dies sollte als Fehler bezeichnet werden, nicht als Vorschlag.

in meinem Fall, wenn ich so etwas in meinem eigenen Code definiert habe

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

Wenn das T von einem npm-Modul stammt, werden beim Versuch, zur Definition zu gelangen, 2 Definitionen angezeigt. Mein eigener Code und die Typisierungsdefinition. Wenn ich zur Typdefinition gehe, geht es direkt zur Definitionsdatei.
Im ersten Fall sollte es gleich zur Definition gehen.
Um dies zu umgehen, habe ich den Editor --> goto location: multiple in goto statt peek geändert

Ich brauche diese Funktion. Wie kann ich bei der Umsetzung helfen?

+1 dafür bitte!

seit 2015 und keine lösungen :(

Das OP hat gefragt, ob wir zu .ts Dateien gehen könnten, wenn wir .d.ts -Dateien finden – wenn Sie die .ts Dateien mit den .d.ts Dateien und der Erklärung versenden Karten generiert von --declarationMaps , das ist unser aktuelles Verhalten (also das ist ziemlich fertig). Die _second_-Anfrage in diesem Thread, die wir jetzt hier verfolgen, ist eine Option, um zur Ausgabedatei .js zu gehen (was nützlich sein könnte, wenn zum Beispiel die .ts Quellen t versendet). In Bezug auf die Implementierung ist das nur eine Frage der Kombination der Deklarations-Quellzuordnungen und Javascript-Quellzuordnungen, die wir bereits ausgeben, aber was wir noch nicht entschieden haben, ist, wie eine solche Funktion dargestellt werden soll. Go to implementation in ts-Code hat bereits eine nützliche Bedeutung für den meisten Code (was zur Definition geht, aber Implementierungs-/Wert-Deklarationen bevorzugen) ... ändern wir das in irgendeiner Weise (z Datei, versuchen Sie stattdessen, in eine js-Datei aufzulösen), oder fügen wir einen neuen Endpunkt hinzu? Wenn letzteres, müssen wir mit dem vscode-Team darüber sprechen, wie wir es an die Oberfläche bringen wollen.

@DanielRosenwasser Ehrlich gesagt, was wir hier wirklich brauchen, ist nur eine genauere Beschreibung, wie wir so etwas

Programmierer aus dem vscode-Team können Ideen vorschlagen, wie dies implementiert werden sollte, z. B. Go to js implementation oder so ähnlich Start.

Ich verstehe, dass es hier mehrere verwandte Probleme gibt. (1) ist der große, aber wir sollten auch die anderen im Auge behalten:
1) Es gibt keine einfache Möglichkeit, zur JS- oder TS-Implementierung eines TS-Typs zu navigieren, wenn dieser Typ in einem DefinitelyTyped-Paket deklariert ist. (oder andere Fälle, in denen .d.ts nicht mit der Implementierung zusammengelegt wird)
2) Gehe zu Typdefinition funktioniert nicht, wenn die Auswahl selbst ein Typ ist. Sie erhalten die Fehlermeldung "Keine Typdefinition gefunden".
3) Gehe zu Definition bei einem Nicht-Typ-Bezeichner verhält sich inkonsistent. Manchmal navigiert es zur Implementierung, manchmal nicht. Theoretisch ist dies dasselbe wie (1), aber es ist auch möglich, (1) zu lösen, während diese Inkonsistenz beibehalten wird.

Ich denke, es wäre für Benutzer einfacher, alle drei Probleme zu lösen, _ohne_ eine dritte "Gehe zu"-Menüoption hinzuzufügen. Stattdessen würde ich vorschlagen, nur zwei Menüpunkte beizubehalten, sie aber konsistenter zu verhalten:

• Gehe zu Definition sollte immer zur Implementierung navigieren , unabhängig davon, ob es sich um lokalen Code, ein node_modules-Paket mit integrierten .d.ts-Dateien oder eine vom JS-Paket getrennte DefinitelyTyped-Definition handelt.
• Gehe zu Typdefinition sollte immer zur TS-Deklaration navigieren , unabhängig davon, ob es sich bei der Auswahl um einen Typ- oder einen Nicht-Typ-Bezeichner handelt.

Gibt es andere gängige TS-Anwendungsfälle, die eine dritte Wahl erfordern?

Übrigens, ich denke, wir könnten "Go To Definition" in "Go To Implementation" umbenennen, wenn wir die Unterscheidung klarer machen wollten, aber IMHO scheint dies eine optionale Änderung zu sein. Konsistenz (unabhängig vom Namen) ist das höherwertige Bit.

Es gibt keine einfache Möglichkeit, zur JS- oder TS-Implementierung eines TS-Typs zu navigieren, wenn dieser Typ in einem DefinitelyTyped-Paket deklariert ist. (oder andere Fälle, in denen .d.ts nicht mit der Implementierung zusammengelegt wird)

_Technisch_ wenn Sie einige Sourcemaps von Hand drehen wollten, um mit einem DT-Paket zu gehen, könnte es schon klappen. Aber hier gibt es definitiv keine automatisierte Lösung. Jede Lösung, die wir haben, basiert auf der Verbesserung von Szenarien mit TS-Compiler-Ausgabe. Dies sind die einzigen Zeiten, in denen wir die zusätzlichen Metadaten ausgeben können, die erforderlich sind, um die richtigen Verknüpfungen zwischen Dateien herzustellen. Einige Pakete unterstützen dies heute, glaube ich - ich habe neulich das azure js sdk verwendet und einige Dinge debuggt und war angenehm überrascht, als ich zu einigen Definitionen ging und entdeckte, dass sie in der Originalquelle waren. Also ja, es funktioniert mit TS-Quellen, die aktuelle --declarationMaps Ausgaben enthalten.

Gehe zu Typdefinition funktioniert nicht, wenn die Auswahl selbst ein Typ ist. Sie erhalten die Fehlermeldung "Keine Typdefinition gefunden".

Ich finde, ihr solltet dazu ein neues Thema aufmachen. Das ist nur ein Fehler von Ausnahmen/Bug, imo. Minimal könnte der Fehler verbessert werden - so etwas wie "Auswahl ist nur ein Typ und hat daher keine Typdefinition, die mit seinem Wert verbunden ist".

Gehe zu Definition bei einem Bezeichner ohne Typ verhält sich inkonsistent. Manchmal navigiert es zur Implementierung, manchmal nicht. Theoretisch ist dies dasselbe wie (1), aber es ist auch möglich, (1) zu lösen, während diese Inkonsistenz beibehalten wird.

Es geht zur _ersten_ Definition, wobei first ziemlich willkürlich ist und auf Dingen wie der Reihenfolge basiert, in der die Dateien geladen wurden. Das peek Fenster ist zugegebenermaßen nützlicher, da es alle Definitionsseiten anzeigt. "Implementierungen" kommen nicht ins Spiel.

Als Nutzer bin ich zufrieden, wenn es so funktioniert:

Strg+Klick auf ein Symbol (ich benutze meistens nur dies, um im Code zu navigieren) führt derzeit entweder zu einer Implementierung (wenn es sich innerhalb des Pakets befindet, das in VS-Code bearbeitet wird) oder zur Deklaration (wenn es ein Paket aus den Abhängigkeiten ist) . Ersteres bedarf keiner Überlegung. Das zweite, wenn es zur Deklaration geht, möchte ich Strg+Klicken auf die Deklaration und sie navigiert mich zur Implementierung, wenn sie sie für mich finden, herunterladen und öffnen kann. Andernfalls wird eine Meldung angezeigt, welches Problem das Auffinden / Öffnen der Quellen verhindert hat. Wenn es so funktionieren würde, wäre es toll.

Ich glaube, es gibt die folgenden Szenarien beim Auffinden des ursprünglichen Quellcodes:

1. Ein Paket wird in Typoskript und Original-Quellcode in einem externen Repository geschrieben und entweder
   a) Verteilung umfasst d.ts und js Dateien ODER
   b) die Verteilung umfasst d.ts , js und ts Dateien
2. Ein Paket wird in Typoskript und Original-Quellcode in das aktuelle Repository geschrieben (Mono-Repo-Fall) und
   a) Verteilung umfasst d.ts und js Dateien
3. Ein Paket ist in Javascript und Original-Quellcode in einem externen Repository geschrieben und entweder
   a) Distribution enthält eigene d.ts und js Dateien ODER
   a) die Distribution enthält nur js Dateien und es werden externe @types Definitionen verwendet
4. Ein Paket wird in Javascript und Original-Quellcode im aktuellen Repository geschrieben (Mono-Repo-Fall) und
   a) Distribution enthält eigene d.ts und js Dateien

1b) - wird selten verwendet, und ich mag diesen Ansatz nicht, da Ressourcen wie Bündelphobie und npm-Trends riesige Paketgrößen melden, die zur Laufzeit nicht wirklich groß sind, aber die Leute beurteilen die Größe anhand dieser Ressourcen. Es ist also keine gute Idee, sich darauf zu verlassen, dass die Betreuer ts Dateien in die Distribution einbinden, aber wenn ts Dateien enthalten sind, ist der Fall sicherlich gelöst.

1a) - (meist?) häufiger Fall. Das Paket sollte irgendwie deklarieren (über package.json oder source maps?), wo sich die Originalquellen beim Kompilieren befanden (wie Microsoft pdb Symboldateien deklarieren) ODER wo sie heruntergeladen werden können, zum Beispiel git+revision+ Weg. VS-Code navigiert zur lokalen Datei oder git fetch zum lokalen Cache und öffnet ihn bei der Navigation von der Deklaration zur Implementierung

2a) - Wenn es möglich ist, den Fall von Mono-Repo automatisch zu erkennen (unter Verwendung einiger Heuristiken), könnte die ursprüngliche Strg+Klick-Navigation die Implementierung direkt öffnen. Wenn es unmöglich ist, ist ein Fallback auf 1a) gut genug

3 interessiert mich weniger, aber es wäre schön, wenn 3a) die JS-Implementierung in der zweiten Strg+Klick-Navigation öffnen könnte. Im Fall von 3b) sollte das @types Paket deklarieren, welche JS-Pakete es annotiert, sodass VS-Code diese Informationen haben könnte, um zur JS-Implementierung im externen Paket zu navigieren.

4 ist mir noch weniger wichtig, aber es könnte das gleiche Verhalten wie 2a) haben - Fallback für 4a) ist 3a)

Ich hoffe es hilft.

1a) - (meist?) häufiger Fall.

Ja, das ist es, was ich sage, wir haben jetzt alle Tools, die wir unterstützen können. Wir können .js.map und .d.ts.map Dateien kombinieren, um eine Zuordnung von .d.ts zu .js zu erstellen (ohne das Zwischenprodukt .ts ). Aber, hm. Wirklich, Sie würden es vorziehen, zur Deklarationsdatei zu gehen und dann erneut zu interagieren, um zu den zugehörigen js? Sie möchten nicht direkt zum js springen?

"Wirklich, Sie möchten lieber zur Deklarationsdatei gehen und dann erneut interagieren, um zu den zugehörigen js zu gelangen? Sie möchten nicht direkt zu den js springen?"

Bei 1a) sind Doppelsprung oder Einzelsprung für mich beide in Ordnung. Obwohl der Einzelsprung als "effizienter" angesehen werden kann, hat der Doppelsprung den Vorteil, den Benutzer daran zu "erinnern", dass der zweite Sprung aus der Sicht des "Bibliotheksverbrauchs" ein Sprung in die Blackbox ist (dh daran erinnern, dass die Quelle Datei, zu der navigiert wird, ist nicht Teil des aktuellen Projekts). Vielleicht könnte dieses Verhalten konfigurierbar gemacht werden.

Bei 3a), 3b) oder 4 möchte ich auf jeden Fall Doppelsprung. Ich möchte zuerst die Deklarationen sehen und erst danach (in sehr seltenen Fällen, wie beim Debuggen) die Implementierung. Wenn Sie direkt zu JS springen und die TS-Deklaration überspringen, werden alle Vorteile der Deklarationen entfernt. Also, ich möchte auf jeden Fall zuerst die TS-Deklaration sehen.

(Kombination von Antworten an @weswigham und @avkonst aus mehreren Beiträgen)

Es geht zur ersten Definition, wobei first ziemlich willkürlich ist und auf Dingen wie der Reihenfolge basiert, in der Dateien geladen wurden.

Warum sollte es im häufigsten Fall, in dem Sie zur Implementierung für ein bestimmtes importiertes Symbol gehen möchten, mehrere Definitionen geben? Ist das eine übliche Situation?

Erstellen Sie eine Zuordnung von .d.ts zu .js (ohne die dazwischenliegenden .ts).

Ich bin mir nicht sicher, ob ich "ohne den Zwischen-TS" verstehe. Meinen Sie, dass VSCode, selbst wenn die ursprüngliche .ts-Quelle verfügbar ist, zu den transpilierten .js navigieren würde? Das scheint eine schlechte Idee zu sein. Wenn die Originalquelle verfügbar ist, sollte VSCode dorthin navigieren – genau wie wenn der Debugger in transpilierten Code mit einer Quellzuordnung einsteigt. Wenn der Paketautor jedoch böse oder faul war und die ursprüngliche TS-Quelle nicht in seine npm-Distribution aufgenommen hat, scheint es für VSCode vernünftig zu sein, auf das transpilierte JS zurückzugreifen und möglicherweise eine Warnmeldung anzuzeigen, die erklärt, warum der Benutzer es sieht solchen seltsamen, unlesbaren Code und um Benutzer zu ermutigen, den Paketautor zu drängen, die Originalquelle in ihr Paket aufzunehmen.

Wirklich, Sie würden es vorziehen, zur Deklarationsdatei zu gehen und dann erneut zu interagieren, um zu den zugehörigen js? Sie möchten nicht direkt zum js springen?

Ich glaube nicht, dass ein zweistufiger Mehrwert wäre. Ich denke, es ist viel besser, eine eindeutige, konsistente UX zu haben: Verwenden Sie "Gehe zu Typdefinition", um zur Typdefinition zu navigieren, und verwenden Sie "Gehe zu Definition" (oder "Gehe zu Implementierung", wie auch immer wir es nennen), um zum Original zu gelangen Quellcode oder, wie oben, in das transpilierte JS, wenn die Originalquelle nicht verfügbar ist.

IMHO ist es viel verwirrender, ein anderes Verhalten zu haben, je nachdem, ob das ausgewählte Symbol in Ihrem eigenen Code oder in node_modules definiert ist. Es sollte keine Rolle spielen. Wenn ich den Typ sehen möchte, sollte mich VSCode zum Typ führen. Wenn ich den Implementierungscode sehen möchte, sollte mich VSCode dorthin führen. Dies gilt insbesondere, weil in großen Organisationen, was "mein Code" und was "Bibliothekscode" ist, nicht immer eine helle Linie ist. Wenn jemand anderes Code in ein gemeinsam genutztes internes Paket umgestaltet, sollte ich nicht ändern müssen, wie ich zu diesem Code navigiere.

Ich möchte zuerst die Deklarationen sehen und erst danach (in sehr seltenen Fällen, wie beim Debuggen) die Implementierung.

Es scheint klarer zu sein, dass der Entwickler explizit wählen muss (indem er den einen oder anderen Menüpunkt auswählt), ob er eine Typdeklaration oder den Implementierungscode anzeigen möchte. Es erscheint unnötig verwirrend, dass die Navigation inkonsistent ist, je nachdem, woher der Code stammt.

> Gehe zu Typdefinition funktioniert nicht, wenn die Auswahl selbst ein Typ ist.
Ich finde, ihr solltet dazu ein neues Thema aufmachen. Das ist nur ein Fehler von Ausnahmen/Bug, imo.

Ja, das könnte definitiv zuerst behoben werden. Ich habe es hier aufgenommen, denn wenn meine bevorzugte Lösung ("Gehe zu Definition navigiert immer zur Implementierung") übernommen wird, werden Benutzer es sich angewöhnen, "Gehe zu Typdefinition" zu verwenden, wenn sie die .d.ts sehen möchten Es wäre seltsam, wenn dies für einen Typ nicht konsistent zu dem Verhalten eines Nicht-Typ-Bezeichners wäre.

"Es geht um die erste Definition, wobei first ziemlich willkürlich ist und auf Dingen wie der Reihenfolge basiert, in der Dateien geladen wurden."

Ich habe in meinen Antworten nicht erwähnt, dass es zur ersten Definition navigieren sollte. Ich sagte bei Strg+Klick auf ein Symbol soll es erst einmal zur Definition gehen (wie es jetzt funktioniert) und erst beim anschließenden Strg+Klick zur Umsetzung.

"Es scheint klarer zu sein, dass der Entwickler explizit wählen muss (indem er den einen oder anderen Menüpunkt auswählt), ob er eine Typdeklaration oder den Implementierungscode anzeigen möchte."

Separate Kontextmenüs sind in Ordnung und eine gute Idee. Sie schließen sich nicht gegenseitig für das Strg+Klick-Verhalten aus.

Ich frage mich, warum an diesem kritischen Fehler noch nicht gearbeitet wird. Es wird immer mehr zur Qual, wenn die Typoskript-Adoption zunimmt.

Ich möchte keine technischen Erklärungen hören, ich möchte wissen, warum dieses Problem nach so vielen Beschreibungen bei verschiedenen Benutzern nicht einmal erkannt wird.

@zjaml möchten Sie, dass es zu TypeScript-Quelldateien oder JavaScript-Quelldateien geht? TypeScript-Quelldateien werden unterstützt. Es sind JavaScript-Quelldateien, für die dieses Problem derzeit noch offen ist.

Tangential verwandt; Ich habe ein Monorepo mit einem gemeinsamen Paket, das auf npm veröffentlicht wird. Aufgrund dieser öffentlichen Schnittstelle ist die Dist js + d.ts-Dateien. Wenn ich im Repo arbeite, springt VSCode immer auf die d.ts statt auf die Quelle. Kennen Sie einen Weg, dies zu umgehen?

@ 0x80 Ich glaube, dieses Problem ist für das gerade beschriebene Szenario noch offen. Ich denke, Sie können dies nur umgehen, wenn das Projekt Open Source ist und Sie es aus der Typescript-Quelle kompiliert haben. Dann könnten Sie das Flag --declarationMaps für den Typescript-Compiler aktivieren, und IDEs, die die Deklarationszuordnungen unterstützen, gehen an die Typescript-Quelle anstelle der d.ts-Dateien.

Das ist wirklich entscheidend. Ich möchte eine einfache Sache: CTLR + Klicken und navigieren Sie zur Datei node_modules/library/source.js oder source.ts. Opensource-Projekt mit 60 node_modules-Abhängigkeiten und Sie können Notepad mit Explorer wieder verwenden.

Als ich mit der rechten Maustaste auf eine Komponente geklickt habe, sah ich: "Gehe zu Definition" und "Gehe zu Typdefinition". Ich dachte "Toll, das ist gut gestaltet, die Lösung für mein Problem ist hier!". Dann habe ich auf "Go to Definition" geklickt und... landete bei der Type Definition.

Das ist wirklich entscheidend. Ich möchte eine einfache Sache: CTLR + Klicken und navigieren Sie zur Datei node_modules/library/source.js oder source.ts. Opensource-Projekt mit 60 node_modules-Abhängigkeiten und Sie können Notepad mit Explorer wieder verwenden.

+1
Gleiches Bedürfnis.

Bei allem Respekt, dass dies nicht umgesetzt wird, ist unglaublich. So ein einfaches, relativ einfach zu
Build-Funktion, die den Leuten viel Zeit sparen würde.

Bei allem Respekt, dass dies nicht umgesetzt wird, ist unglaublich. So ein einfaches, relativ einfach zu
Build-Funktion, die den Leuten viel Zeit sparen würde.

+1

Nun, in der Zwischenzeit, wenn diese Funktion noch nicht verfügbar ist, gibt es einen besseren Workaround, als nach den gesamten node_modules zu suchen? Es ist wirklich unangenehm...
Zum Beispiel gehe ich zur Definition und sie führte mich zu node_modules/@com.abc/sample/lib/core/internal/abc.d.ts wenn sich die gewünschte befindet sich tatsächlich bei node_modules/@com.abc/sample/src/core/internal/abc.ts

@Happin3ss

Gibt es eine bessere Problemumgehung als die Suche nach den gesamten node_modules?

Die aktuelle Lösung von AFAIK sind Deklarationskarten . Dies sind Sourcemaps, die .d.ts-Dateien der entsprechenden TS-Quelle zuordnen. Wenn Sie die Bibliotheken, auf die Sie angewiesen sind, davon überzeugen können, Deklarationszuordnungen zu implementieren (was meiner Meinung nach die Veröffentlichung von .d.ts im Bibliothekspaket erfordert, anstatt sich auf @types zu verlassen), können Sie automatisch von Ihrem Client-Code springen zum ursprünglichen TS (oder sogar JS, wenn der TS-Compiler auf JS verwendet wird?) Quellcode.

Was ich getan habe, ist, nach und nach PRs für meine wichtigsten Abhängigkeiten (zumindest diejenigen, die in TS erstellt wurden) einzureichen, um sie dazu zu bringen, Deklarationszuordnungen hinzuzufügen.

Natürlich wäre es besser, wenn kein Wechsel der Bibliothek erforderlich wäre.

Eine andere Problemumgehung (wenn das Ändern der Bibliothek nicht möglich ist) funktioniert in dem Fall, in dem die Bibliothek .d.ts innerhalb des Pakets bündelt, aber keine Deklarationszuordnungen hat. In diesem Fall verwende ich Gehe zu Definition, um zur Typdeklaration zu gelangen, und klicke dann in VSCode auf die Schaltfläche Explorer, um die Ordner-Seitenleiste anzuzeigen. Das bringt mich normalerweise sehr nahe an den src Ordner für das Paket, sodass ich, anstatt alle node_modules durchsuchen zu müssen, einfach in den richtigen Ordner navigieren und die richtige Datei öffnen kann. Dies ist abhängig von einer eindeutigen Dateibenennung etc. und ist kein Allheilmittel.

Nur um 100% klar zu sein – ich würde gerne eine bessere Lösung für Bibliotheken sehen, insbesondere für Bibliotheken. diejenigen, bei denen .d.ts separat vom Paket erstellt wird.

Ich bin mir nicht sicher, ob ich es übersehen habe, aber es wäre wirklich nützlich, um zu verstehen, was passiert, tatsächliche Minimalbeispiele für Quellen, Deklarationen und Deklarationszuordnungen zu haben. Ich habe noch nie gesehen, dass entweder Go to Definition, Go to Type Definition oder Go to Implementations tatsächlich zu etwas anderem als einer .d.ts Datei für transpilierte TS gehen. Ich habe gerade versucht, ein einfaches Beispiel zu machen, und es funktioniert nicht; Ich kann VS Code nicht dazu bringen, zu etwas anderem als der .d.ts Datei zu gehen, obwohl die .d.ts.map liegt. Ich habe auch jemanden mit dem gleichen Problem gefunden, der ignoriert wurde.

Es ist verständlich, dass es schwierig wäre, externe Eingaben wie @types zu unterstützen, aber was sagt es aus, dass selbst der "glückliche Weg" nicht zum Laufen gebracht werden kann?

Es gibt viele Bibliotheken, die Deklarationsdateien generieren, aber keine Deklarationszuordnungen, und es ist unklar, was das Argument für deren Aktivierung wäre. Diese Option wurde ohne eine klare Erklärung hinzugefügt, zumindest eine, die ich finden könnte.

Ja, ich bestätige, dass Deklarationszuordnungen das Problem nicht lösen. Mein Projekt hat Deklarationszuordnungen, aber vscode navigiert nicht über .d.ts-Dateien hinaus.

Es wäre sicher toll, wenn dies passieren würde.

Wenn es einen "Elefanten im Raum" von Problemen für MS vscode-Entwickler gibt, ist dies der Fall.

Irgendwelche Updates zu diesem?
Ich habe gerade beschlossen, einen großen Schritt zu machen: von JS zu TS zu wechseln. Ich dachte - "Was mache ich falsch?" aber eigentlich ist es ein unerwartetes Verhalten von VSCode

Irgendwelche Updates zu diesem?
Ich habe gerade beschlossen, einen großen Schritt zu machen: von JS zu TS zu wechseln. Ich dachte - "Was mache ich falsch?" aber eigentlich ist es ein unerwartetes Verhalten von VSCode

Es war eine lange Geschichte, seit dieses Verhalten aufgekommen war. Nun, hier ist nichts los. Bisher kein Plan.
Für mich verwende ich vscode weiterhin als eine Art Editor, und Intellij-Produkte (IDEA) für meine Codierungssachen, auch wenn ich es nicht so mag.

Geöffnet für 5 Jahre, hoffe es wird 2025 behoben

Ich habe in #39426 fehlgeschlagene Tests erstellt, weiß aber nicht, wie ich sie implementieren soll

Nur ein weiterer miserabler Kommentar von ts dev, der jeden Tag durch die Hölle geht, um Definitionen zu finden

Das ist verrückt... Ich dachte, ich wäre nur ein TS-Noob, aber jetzt sehe ich, dass das Verhalten, das ich bekomme, tatsächlich "Standard" ist???? Es ist so frustrierend, dass jede andere IDE / Sprache, die ich verwendet habe, dies bei der ersten Veröffentlichung implementiert hat ... :( Ich liebe VS-Code, aber ehrlich gesagt könnte dies ein Deal Breaker sein

Kann jemand erklären, warum go to definition/implementation Funktionen in VSCode mit Python-Erweiterungen für die Python-Sprache besser funktionieren (es funktioniert zumindest) als für JS mit nativen integrierten Lösungen?

Also, was ist los?
Ich verwende scss.d.ts für CSS-Module und kann nicht zu scss springen.

Auch beim Erstellen einfacher .js und dementsprechend d.ts kann ich nicht direkt zu js springen

Warum nicht webstorm verwenden?
es kann dieses Problem lösen!!!
meine Version 2020.1

Warum nicht webstorm verwenden?
es kann dieses Problem lösen!!!
meine Version 2020.1

Weil es keine Open-Source-Lösung und nicht kostenlos ist

Bitte beheben Sie dies.

Es ist absolut klar, dass dieses Problem nur behoben werden kann, wenn irgendein Manager von Microsoft übernimmt, dieses Problem gemanagt und koordiniert werden muss, ein Manager einen Workflow entwickelt und die Arbeit an Programmierer zuweist. ☝
Dieses Problem muss an das Management geschickt werden, um es zu übernehmen und es entscheidet, wie es umgesetzt wird.
Wenn hier also jemand kompetenter von Microsoft ist, kann er es versuchen. 😊