Typescript: Activer Aller à la mise en œuvre dans les éditeurs Typescript

Donc, vous voulez que cette fonctionnalité passe au .js si disponible, à condition que la définition soit ambiante, n'est-ce pas ?

@RyanCavanaugh @mousetraps @bowdenk7

Donc, vous voulez que cette fonctionnalité passe au .js correspondant s'il est disponible, à condition que la définition soit ambiante, n'est-ce pas ?
Oui c'est un scénario qui serait très utile pour la productivité. Cela seul serait très précieux. Je pense que l'auteur d'atom-typescript pense que plus de crochets dans le compilateur Typescript lui faciliterait la mise en œuvre. Je ne sais pas s'il s'agit d'informations sur les numéros de ligne d'implémentation de js sont des informations que le compilateur dactylographié connaîtrait généralement en interne.

De plus, un autre scénario permettrait un saut vers la définition de fichier dactylographié .ts d'origine dans la bibliothèque utilisée par l'application. J'imagine que ces informations sont disponibles pré-compilées dans les fichiers d.ts et .js. Nous avons maintenant des ensembles complets de bibliothèques écrites dans des fichiers .ts en tant que source produisant la syntaxe ES5 js. Ce serait bien d'avoir la possibilité de sauter à la définition d'implémentation du script d'origine dans les fichiers .ts.

Je suis conscient que cela demande encore plus de passer à l'implémentation du fichier .ts dans la bibliothèque requise, car cela peut nécessiter l'utilisation de la carte source ou la distribution de la source/du lien vers la source ts d'origine. Il me semblerait que le compilateur typescript qui génère la bibliothèque initiale de fonctions et de classes connaîtrait les lignes où se trouve l'implémentation et pourrait conserver les numéros de ligne lorsque la bibliothèque est distribuée d'une manière ou d'une autre afin que le compilateur typscript de l'application utilisant la classe pourrait savoir à quelle ligne sauter dans la bibliothèque.

Ces informations sur le numéro de ligne de la fonction/classe d'implémentation sont-elles disponibles dans les cartes source ? Existe-t-il d'autres sources de ces informations ?

Étant donné que nous allons utiliser le drapeau --allowJS , le service de langue devrait pouvoir fonctionner avec les fichiers JS.

Je ne sais pas comment les fichiers .d.ts et les fichiers .js fonctionnent actuellement ensemble à cet égard. @sheetalkamat en sait probablement (certainement) plus que moi à ce sujet.

Réouverture, car accéder aux fichiers js n'est pas encore tout à fait pris en charge

Des mises à jour sur celui-ci? L'état actuel du dactylographe est que vous ne pouvez pas passer directement à l'implémentation du code dans de nombreuses bibliothèques importantes.

Ce problème a été déplacé/fermé/dupé/dédupliqué plusieurs fois et la correction de ce bogue pourrait être un énorme gain de productivité.

https://github.com/ubershmekel/vscode-ts-goto-source a un projet qui reproduit le problème. Comme expliqué dans https://github.com/Microsoft/vscode/issues/26325 et référencé dans https://github.com/Microsoft/vscode/issues/10806 et https://github.com/Microsoft/vscode/issues /18321

Remarque J'ai dû utiliser "typescript.disableAutomaticTypeAcquisition": true partir d'un point pour utiliser le javascript "aller à la définition" car il semble que les fichiers .d.ts prennent le relais s'ils sont trouvés.

@DanielRosenwasser Des mises à jour à ce sujet ? - La fonctionnalité la plus recherchée pour moi.

C'est particulièrement ennuyeux si vous travaillez dans un monorepo écrit entièrement en Typescript. J'ai plusieurs fois lors de l'ajout d'un champ à un type ou à des modifications plus petites similaires utilisées "aller à la définition", l'ai ajouté, puis l'ai trouvé manquant à nouveau en réalisant que je l'avais ajouté au fichier .d.ts et non au .ts réel

@DanielRosenwasser Est-ce que ça avance ? j'adorerais vraiment cette fonction

même problème. Vous voulez "Aller à l'implémentation" du code source, pas de xx.d.ts

Oui, plusieurs fois par jour, j'édite par erreur le fichier de déclaration après avoir utilisé cmd + clic et je me retrouve confus lorsque le code ne s'exécute pas correctement. Surtout que src et dec se ressemblent beaucoup. Ce serait génial s'il y avait un moyen de choisir si je veux aller à la source de la déclaration, ou encore mieux si VSCode comprendrait cela car aller à la source est toujours préférable à mon humble avis (si elle est disponible).

aller à la source est toujours plus préférable à mon humble avis (s'il est disponible)

Lorsque la source est en TS. Si la source est en JS, il y a une bonne raison d'aller dans le .d.ts

Lorsque la source est en TS. Si la source est en JS, il y a une bonne raison d'aller dans le .d.ts

Pourquoi? Je peux simplement survoler pour voir la définition du type. Quoi qu'il en soit, il devrait y avoir une commande distincte pour la définition du type par rapport à l'implémentation.

Y a-t-il une raison pour laquelle cela est toujours en attente? Une solution de contournement, une alternative ou autre ? Merci d'avance

Étant donné que l'analyseur Typescript génère souvent les fichiers d.ts à partir des fichiers d'implémentation .ts. Cette association entre les fichiers d.ts et .ts pourrait-elle être préservée (peut-être une sortie avec une option de compilateur dactylographié) afin que les éditeurs dactylographiés puissent amener les développeurs à une liste des classes ou fonctions d'implémentation ?

J'ai une branche de #21930 qui permet de produire précisément ces sourcesmaps de fichiers de déclaration (et je les publierai pour examen soit sur demande, soit une fois que #21930 sera fusionné), et je travaille sur l'ajout de la prise en charge dans notre LS pour suivre ces cartes. Nous voulons l'expédier en 2.8.

Alors oui, nous y avons travaillé. Il fallait juste beaucoup de changements internes. ??

Attendez-vous à des mises à jour sur ce problème pour soulager la difficulté de trouver des implémentations en développant manuellement les dossiers sous node_modules et en localisant le fichier du module d'entrée.

Existe-t-il une solution de contournement pour cela?
Comme nous avons un gros module pour nos requêtes de base de données écrit en ts, ce serait vraiment bien de voir le vrai code source avec une seule commande au lieu de chercher dans node_modules.

@derN3rd Il existe vscode-search-node-modules extension node_modules dans le panneau de commande (et j'ai aussi un fork qui ouvre toujours README vscode-open-node-modules )

Je comprends que c'est loin d'être l'UX parfait pour cliquer sur exiger/importer et ouvrir un fichier, mais c'est certainement mieux que de faire défiler node_modules

@derN3rd, nous expédierons un indicateur --declaratrionMap dans la version 2.9 (qui pourrait être publié au cours du mois prochain), et nous avons déjà activé l'accès aux définitions dans le TS source d'origine sur un .d.ts associé en utilisant eux (qui, si vous envoyez des fichiers de déclaration dans votre dossier de modules de nœuds, peuvent obtenir beaucoup de ce que vous voulez). Nous envisageons également de sauter vers/depuis le JS associé, à condition que les sourcesmaps normales soient également activées.

@weswigham merci pour la réponse rapide ! Ça a l'air bien
Pourriez-vous publier une mise à jour ici si la fonctionnalité est prête ou prête à être testée ?

--declarationMap (et la redirection LS associée) fait partie de nos nightlies juste après la sortie de la 2.8. Le seul élément que nous n'avons pas encore fait est le saut de fichier JS, car cela peut nécessiter une coordination supplémentaire de l'éditeur.

Des nouvelles pour ça sur 3.0-rc ?

Même problème avec les fichiers .css et .json . Accédez à Définition et accédez au fichier .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'

Aller à la définition sur ./App.css m'amène à

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 est désormais livré avec TypeScript 3.0.3. Des nouvelles sur ce problème ?

Fonctionne pour moi (cartes de déclaration générées avec TS 2.9.2, exécutant VSCode 1.27.0). Naviguer à partir d'un consommateur d'API (implémenté dans JS) _Aller à la définition_ m'amène à l'implémentation dans le fichier .ts.

@robsman _Go to Definition_ devrait vous amener au code js compilé, tandis que _Go to Type Definition_ devrait vous amener au fichier .d.ts.

Comment utilisez-vous/incluez-vous votre module compilé, pour ouvrir les fichiers sources ?

Ce problème existe toujours pour moi dans VSCode 1.27.0, car les deux fonctions me conduisent au fichier .d.ts

EDIT : Je pense que j'ai mal compris votre commentaire. Cela vous amène-t-il au vrai code ? Si oui, utilisez-vous un monorepo ou votre code compilé est-il expédié dans un propre module npm ? Envoyez-vous les fichiers sources avec votre code compilé ?

@derN3rd re-testé, à la fois _Aller à la définition_ et _Aller à la définition du type_ ainsi que _Peek Definition_ m'amènent au vrai code dans le fichier _.ts_.

La déclaration et l'implémentation de l'API se trouvent toutes deux dans un module distinct auquel le package appelant fait référence en tant que dépendance _git+ssh..._.

@robsman Je pense que Go to Definition devrait me renvoyer à la source de "cette" classe ou fonction dans le fichier source js (si c'est du javascript) à l'intérieur de node_modules non de .d.ts . Comme ça marche dans Sublime Text 3, je veux dire. De toute façon je ne comprends pas pour quoi VSCode cette fonctionnalité dans l'état actuel

L'espoir peut donner la priorité à ce problème, c'est vraiment une grande douleur, à cause de tant de commentaires et de problèmes connexes.

Veuillez m'ajouter à la longue liste de personnes essayant d'utiliser le clic de commande pour naviguer dans le code. Je n'ai pas de TS dans mon projet et le package npm vers lequel je navigue n'utilise pas TS, mais un clic de commande sur require('co-body') m'amène à une définition TS générée en interne. Je suis un utilisateur d'IntelliJ de longue date et, pour cette raison, je reviens toujours à IntelliJ.

c'est une longue demande

J'aime beaucoup VS Code et je viens de démarrer un nouveau projet Node et j'ai décidé d'utiliser TypeScript pour la première fois. Jusqu'à présent, la plupart du temps, c'est bien, mais ce problème a été un point douloureux. Travaillant en open-source, la possibilité de cliquer sur le code source réel dans les dépendances est vitale pour le flux de travail. Je travaille dans des fichiers source TypeScript et j'utilise des modules JS NPM avec des modules @types/xxx associés qui n'ont pas de documentation associée. IntelliSense avec TypeScript est génial, mais ne fournit pas toujours suffisamment d'informations. À tout le moins, pouvoir cliquer directement sur la source du module à partir de l'instruction import serait bien. Je crois que sur certaines bibliothèques qui fonctionnent, et sur d'autres, par exemple Passport, je ne peux pas dépasser les stubs TypeScript auxiliaires dans le module @types .

Cela devrait être étiqueté _Bug_, pas _Suggestion_.

Le manque de navigation dans le code ruine vraiment l'expérience VSCode pour les développeurs JavaScript.

désolé de spammer le fil mais @promaty j'utilise l'extension search-node-modules 😬 pour l'instant

WebStorm a le même comportement : StackOverflow , BugTracker

• VSCode a des actions "Aller à la définition" et "Aller à la définition du type"

• WebStorm a des actions "Aller à la déclaration" et "Aller à la déclaration de type"

Mais lors de l'utilisation de TypeScript, les deux IDE font la même chose : allez toujours à la définition de type !

"Aller à la définition" et "Aller à la définition de type", lorsqu'ils sont utilisés sur les bibliothèques node_modules/ , m'amènent tous deux à des fichiers .d.ts . Je suis sur le dernier code VS au moment de la rédaction (1.34.0).

Par exemple : npm package @angular/[email protected] , lorsque j'importe TestBed de @angular/core/testing et que j'essaie de voir la définition de TestBed.createComponent , j'obtiens deux choses différentes :

• "Aller à la définition" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts ligne 117
• "Aller à la définition du type" -> node_modules/@angular/core/testing/src/component_fixture.d.ts ligne 14

Cela signifie essentiellement que le code source Angular m'est caché dans VS Code 😞 Je ne sais pas si c'est un symptôme de la façon dont la bibliothèque Angular est écrite, ou comment TypeScript/VS Code trouve les implémentations source.

Tout ce que je sais, c'est que je ne peux utiliser de manière fiable "Aller à la définition" et "Aller à la définition du type" que sur mon propre code, auquel cas je suis directement redirigé vers la source ; Je ne suis jamais montré un fichier .d.ts pour mon propre code.

Nous devons rechercher manuellement les codes sources pour l'instant :/

Aw, je viens de comprendre que d'une manière ou d'une autre, Intellij IDEA a cette fonction qui fonctionne très bien, même si je suis sur le même projet, en utilisant Typescript 3.0.1

J'ai pensé que la priorité de cette question devrait être augmentée.

Nous devons commander + , pour ouvrir les paramètres de l'espace de travail -> décocher Use Ignore Files -> supprimer Search: Exclude: **/node_modules , et rechercher manuellement les codes sources.

TOUS LES JOURS!

C'est pourquoi flow est toujours utile.

Quelqu'un de l'équipe dactylographié pourrait-il suggérer où dans le code cela peut être potentiellement corrigé ?

Une chose amusante est que si certains packages n'ont pas de types disponibles, "Aller à la définition de type" fonctionne mieux pour cela. Cela signifie qu'il est préférable de ne pas utiliser de saisie si vous aimez les fonctionnalités "Aller à" 😄

Voici un screencast qui montre que je suis capable d'accéder à la définition de packages device qui n'ont pas de saisie, mais compression m'amène à un fichier de saisie aléatoire :

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh Je dois être d'accord avec d'autres personnes, cela devrait être étiqueté comme un bogue, pas comme une suggestion ..

dans mon cas, si j'ai quelque chose comme ça défini dans mon propre code

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

si le T vient d'un module npm, quand j'essaie d'aller à la définition, il m'affichera 2 définitions. Mon propre code et la définition de frappe. Si je vais taper la définition, cela va directement au fichier de définition.
Dans le premier cas, il faut aller directement à la définition.
Pour contourner ce problème, j'ai changé l'éditeur --> goto location: multiple en goto au lieu de peek

J'ai besoin de cette fonctionnalité. Comment puis-je aider à sa mise en œuvre ?

+1 pour cela s'il vous plaît !

depuis 2015 et aucune solution :(

L'OP demandait si nous pouvions aller aux fichiers .ts lorsque nous trouvons des fichiers .d.ts - si vous expédiez les fichiers .ts avec les fichiers .d.ts et la déclaration maps générées par --declarationMaps , c'est notre comportement actuel (donc c'est plutôt fait). La _seconde_ requête dans ce fil, que nous suivons maintenant ici, est une option pour accéder au fichier de sortie .js (ce qui pourrait être utile si, par exemple, les sources .ts sont ' t expédié). Du point de vue de l'implémentation, il s'agit simplement de combiner les cartes source de déclaration et les cartes source javascript que nous émettons déjà, mais ce que nous n'avons pas encore décidé, c'est comment une telle fonctionnalité devrait être présentée. Go to implementation dans le code ts a déjà une signification utile pour la plupart du code (qui va à la définition, mais préfère les déclarations d'implémentation/valeur)... modifions-nous cela d'une manière ou d'une autre (disons, si nous résolvons une déclaration fichier, essayez de résoudre en un fichier js à la place), ou ajoutons-nous un nouveau point de terminaison ? Si c'est plus tard, nous devons discuter de la façon dont nous voulons le faire apparaître avec l'équipe vscode.

@DanielRosenwasser honnêtement, ce dont nous avons vraiment besoin ici, c'est juste une description plus détaillée de la manière exacte dont nous voulons exposer une chose comme celle-ci - les outils pour le faire sont maintenant en place.

Les codeurs de l'équipe vscode peuvent proposer des idées sur la façon dont cela devrait être mis en œuvre, par exemple Go to js implementation ou quelque chose comme ça, une première bonne étape serait de créer un ticket sur vscode issue tracker et de croiser ces tickets afin que la communication puisse commencer.

Je crois comprendre qu'il y a plusieurs problèmes connexes ici. (1) est le plus important, mais nous devons également garder les autres à l'esprit :
1) Il n'y a pas de moyen simple de naviguer vers l'implémentation JS ou TS d'un type TS si ce type est déclaré dans un package DefinitelyTyped. (ou d'autres cas où .d.ts n'est pas colocalisé avec l'implémentation)
2) Aller à la définition de type ne fonctionne pas lorsque la sélection est elle-même un type. Vous obtiendrez une erreur "aucune définition de type trouvée".
3) Go To Definition sur un identificateur de non-type se comporte de manière incohérente. Parfois, il naviguera vers l'implémentation, parfois non. En théorie, c'est la même chose que (1), mais il est également possible de résoudre (1) tout en laissant cette incohérence en place.

Je pense qu'il serait plus simple pour les utilisateurs de résoudre les trois problèmes _sans_ ajouter une troisième option de menu "Aller à". Au lieu de cela, ma suggestion serait de ne conserver que deux éléments de menu mais de les faire se comporter de manière plus cohérente :

• Go To Definition doit toujours naviguer vers l'implémentation , qu'il s'agisse de code local, d'un package node_modules avec des fichiers .d.ts intégrés ou d'une définition DefinitelyTyped distincte du package JS.
• Aller à la définition de type doit toujours naviguer jusqu'à la déclaration TS , que la sélection soit un identificateur de type ou non.

Existe-t-il d'autres cas d'utilisation courants de TS qui nécessitent un troisième choix ?

BTW, je suppose que nous pourrions renommer "Aller à la définition" en "Aller à l'implémentation" si nous voulions rendre la distinction plus claire, mais à mon humble avis, cela semble être un changement facultatif. La cohérence (quel que soit le nom) est le bit de poids fort.

Il n'y a pas de moyen simple de naviguer vers l'implémentation JS ou TS d'un type TS si ce type est déclaré dans un package DefinitelyTyped. (ou d'autres cas où .d.ts n'est pas colocalisé avec l'implémentation)

_Techniquement_ si vous vouliez faire tourner à la main quelques sourcesmaps pour aller avec un package DT, cela pourrait déjà fonctionner. Mais il n'y a certainement pas de solution automatisée ici. Toute solution que nous avons est basée sur l'amélioration des scénarios impliquant la sortie du compilateur TS, ce sont les seuls moments où nous pouvons extraire les métadonnées supplémentaires nécessaires pour faire les associations correctes entre les fichiers. Certains packages prennent en charge cela aujourd'hui, je crois - j'utilisais le SDK azure js l'autre jour et déboguais certaines choses, et j'ai été agréablement surpris lorsque je suis allé à certaines définitions et que j'ai découvert qu'elles étaient dans la source d'origine. Donc oui, cela fonctionne avec les sources TS qui ont une sortie --declarationMaps à jour fournie avec elles.

Aller à la définition de type ne fonctionne pas lorsque la sélection est elle-même un type. Vous obtiendrez une erreur "aucune définition de type trouvée".

Je pense que vous devriez tous ouvrir un nouveau numéro sur celui-là. C'est juste un échec des attentes/bug, imo. Au minimum, l'erreur pourrait être améliorée - quelque chose comme "la sélection n'est qu'un type et n'a donc aucune définition de type associée à sa valeur".

Aller à la définition sur un identifiant de non-type se comporte de manière incohérente. Parfois, il naviguera vers l'implémentation, parfois non. En théorie, c'est la même chose que (1), mais il est également possible de résoudre (1) tout en laissant cette incohérence en place.

Cela va à la _première_ définition, où la première est assez arbitraire, et basée sur des éléments tels que les fichiers de commande ont été chargés. La fenêtre peek est certes plus utile, car elle affiche tous les sites de définition. Les "implémentations" n'entrent pas en ligne de compte.

En tant qu'utilisateur, je serai satisfait, si cela fonctionnait comme ceci :

Ctrl+Clic sur un symbole (je n'utilise principalement cela que pour naviguer dans le code) amène actuellement soit à une implémentation (s'il se trouve dans le package en cours d'édition dans VS Code) soit à la déclaration (s'il s'agit d'un package des dépendances) . Le premier ne nécessite pas de considération. Le second, quand il va à la déclaration, je voudrais Ctrl+Clic sur la déclaration et il me dirige vers l'implémentation, s'il peut le localiser, le télécharger et l'ouvrir pour moi. Sinon, il affiche un message indiquant quel problème a empêché la recherche/l'ouverture des sources. Si ça fonctionnait comme ça, ce serait génial.

Je pense qu'il existe les scénarios suivants avec la localisation du code source d'origine :

1. Un package est écrit en tapuscrit et code source original dans un référentiel externe et soit
   a) la distribution comprend les fichiers d.ts et js OU
   b) la distribution comprend les fichiers d.ts , js et ts
2. Un package est écrit en tapuscrit et code source original dans le référentiel actuel (cas mono repo) et
   a) la distribution comprend les fichiers d.ts et js
3. Un package est écrit en javascript et le code source d'origine dans un référentiel externe et soit
   a) la distribution comprend ses propres fichiers d.ts et js OU
   a) la distribution comprend uniquement des fichiers js et des définitions externes @types sont utilisées
4. Un package est écrit en javascript et code source original dans le référentiel courant (cas mono repo) et
   a) la distribution comprend ses propres fichiers d.ts et js

1b) - est rarement utilisé, et je n'aime pas cette approche car des ressources telles que bundlephobia et les tendances npm rapporteront des tailles de paquet énormes, qui ne sont pas vraiment énormes en temps d'exécution, mais les gens jugent la taille en fonction de ces ressources. Donc, compter sur les responsables pour inclure les fichiers ts avec la distribution n'est pas une bonne idée, mais certainement si les fichiers ts sont inclus, le cas est résolu.

1a) - cas (le plus ?) fréquent. Le package doit en quelque sorte déclarer (via package.json ou des cartes sources ?) où se trouvaient les sources d'origine lors de la compilation (comme les fichiers de symboles Microsoft pdb déclarent) OU où peut être téléchargé depuis, par exemple git+revision+ chemin. Le code VS naviguerait vers le fichier local ou git fetch vers le cache local et l'ouvrirait lors de la navigation de la déclaration à l'implémentation

2a) - s'il est possible de détecter automatiquement le cas du dépôt mono (en utilisant certaines heuristiques), la navigation originale Ctrl+Clic pourrait ouvrir l'implémentation directement. Si c'est impossible, le repli sur 1a) est suffisant

Je me fiche de 3, mais ce serait bien si 3a) pouvait ouvrir l'implémentation JS lors de la deuxième navigation Ctrl + Clic. Dans le cas de 3b), le package @types doit déclarer les packages JS qu'il annote, afin que le code VS puisse disposer de ces informations pour accéder à l'implémentation JS dans le package externe.

Je me soucie encore moins de 4, mais cela pourrait avoir le même comportement que 2a) - le repli pour 4a) est 3a)

J'espère que ça aide.

1a) - cas (le plus ?) fréquent.

Oui, c'est ce que je dis, nous avons tous les outils en place pour soutenir maintenant. Nous pouvons combiner des fichiers .js.map et .d.ts.map pour produire un mappage de .d.ts à .js (sans l'intermédiaire .ts ). Mais, hum. Vraiment, vous préférez aller dans le fichier de déclaration, puis interagir à nouveau pour accéder au js associé ? Vous ne voudriez pas sauter directement au js ?

« Vraiment, vous préféreriez accéder au fichier de déclaration, puis interagir à nouveau pour accéder au js associé ? Vous ne voudriez pas sauter directement au js ? »

Dans le cas de 1a), le double saut ou le simple saut me conviennent tous les deux. Bien que le saut simple puisse être considéré comme "plus efficace", le double saut a l'avantage de "rappeler" à l'utilisateur que le deuxième saut est un saut vers la boîte noire du point de vue de la "consommation de la bibliothèque" (c'est-à-dire de rappeler que la source le fichier en cours de navigation ne fait pas partie du projet en cours). Peut-être que ce comportement pourrait être rendu configurable.

Dans le cas de 3a), 3b) ou 4, je veux certainement un double saut. Je veux d'abord voir les déclarations et seulement après cela (dans de très rares cas, comme le débogage) l'implémentation. Passer directement à JS en sautant la déclaration TS supprime tous les avantages des déclarations. Donc, je veux absolument voir la déclaration TS en premier.

(combinaison des réponses à @weswigham et @avkonst à partir de plusieurs publications)

Cela va à la première définition, où la première est assez arbitraire et basée sur des éléments tels que les fichiers de commande ont été chargés.

Dans le cas le plus courant où vous souhaitez accéder à l'implémentation d'un symbole importé particulier, pourquoi y aurait-il plusieurs définitions ? Est-ce une situation courante ?

produire un mappage de .d.ts à .js (sans l'intermédiaire .ts).

Pas sûr de comprendre "sans le TS intermédiaire". Voulez-vous dire que même si la source .ts d'origine est disponible, VSCode naviguerait vers le .js transpilé ? Cela semble être une mauvaise idée. Si la source d'origine est disponible, alors VSCode doit y naviguer, comme il le ferait lorsque le débogueur entre dans le code transpilé qui a un sourcemap. Cela dit, si l'auteur du package était méchant ou paresseux et n'a pas inclus la source TS d'origine dans sa distribution npm, il semble alors raisonnable que VSCode se replie sur le JS transpilé et affiche peut-être un message d'avertissement expliquant pourquoi l'utilisateur voit un code aussi étrange et illisible et d'encourager les utilisateurs à harceler l'auteur du package pour qu'il inclue la source d'origine dans son package.

Vraiment, vous préférez aller dans le fichier de déclaration, puis interagir à nouveau pour accéder au js associé ? Vous ne voudriez pas sauter directement au js ?

Je ne pense pas qu'une démarche en deux étapes ajouterait de la valeur. Je pense qu'il est bien mieux d'avoir une UX distincte et cohérente : utilisez "Aller à la définition de type" pour accéder à la définition de type, et utilisez Aller à la définition (ou Aller à l'implémentation - quel que soit le nom que nous choisissons) pour accéder à l'original code source ou, comme ci-dessus, au JS transpilé si la source d'origine n'est pas disponible.

À mon humble avis, il est beaucoup plus déroutant d'avoir un comportement différent selon que le symbole sélectionné est défini dans votre propre code ou dans node_modules. Cela ne devrait pas avoir d'importance. Si je veux voir le type, VSCode devrait m'amener au type. Si je veux voir le code d'implémentation, VSCode devrait m'y emmener. Cela est particulièrement vrai parce que, dans les grandes organisations, ce qui est « mon code » et ce qui est « le code de la bibliothèque » n'est pas toujours une ligne claire. Si quelqu'un d'autre refactorise le code dans un package interne partagé, je ne devrais pas avoir à changer la façon dont je navigue vers ce code.

Je veux d'abord voir les déclarations et seulement après cela (dans de très rares cas, comme le débogage) l'implémentation.

Il semble qu'il soit plus clair d'exiger du développeur qu'il choisisse explicitement (en choisissant un élément de menu ou un autre) s'il souhaite voir une déclaration de type ou afficher le code d'implémentation. Le fait que la navigation soit incohérente en fonction de l'origine du code semble inutilement déroutant.

> Aller à la définition de type ne fonctionne pas lorsque la sélection est elle-même un type.
Je pense que vous devriez tous ouvrir un nouveau numéro sur celui-là. C'est juste un échec des attentes/bug, imo.

Oui, cela pourrait certainement être corrigé en premier. Je l'ai inclus ici car si ma solution préférée ("Aller à la définition navigue toujours vers l'implémentation") est adoptée, les utilisateurs prendront l'habitude d'utiliser Aller à la définition de type chaque fois qu'ils veulent voir le .d.ts, donc il Ce serait bizarre si faire cela sur un type n'agissait pas de manière cohérente sur la façon dont il agit pour un identifiant de non-type.

"Cela va à la première définition, où la première est assez arbitraire, et basée sur des éléments tels que les fichiers de commande ont été chargés."

Je n'ai pas mentionné dans mes réponses qu'il devrait naviguer vers la première définition. J'ai dit sur Ctrl + Clic sur un symbole qu'il devrait d' abord aller à la définition (comme cela fonctionne maintenant) et uniquement sur le Ctrl + Clic suivant à l'implémentation.

"Il semble qu'il soit plus clair d'exiger du développeur qu'il choisisse explicitement (en choisissant un élément de menu ou un autre) s'il souhaite voir une déclaration de type ou afficher le code d'implémentation."

Des menus contextuels séparés sont une bonne idée. Ils ne s'excluent pas mutuellement avec le comportement Ctrl+Clic.

Je me demande pourquoi ce bogue critique n'est pas encore traité. Cela devient de plus en plus pénible à mesure que l'adoption du tapuscrit augmente.

Je ne veux pas entendre d'explications techniques, je veux savoir pourquoi ce problème n'est même pas reconnu après tant de descriptions sur différents utilisateurs.

@zjaml voulez-vous qu'il aille dans les fichiers source TypeScript ou les fichiers source JavaScript ? Les fichiers source TypeScript sont pris en charge. Ce problème est actuellement toujours ouvert pour les fichiers source JavaScript.

Liés tangentiellement ; J'ai un monorepo avec un package commun qui est publié sur npm. En raison de cette interface publique, la dist est constituée de fichiers js + d.ts. Lorsque je travaille dans le référentiel, VSCode passe toujours au d.ts au lieu de la source. Connaissez-vous un moyen de contourner cela?

@ 0x80 Je pense que ce problème est toujours ouvert pour le scénario que vous venez de décrire. Je pense que la seule façon de contourner ce problème est si le projet est open source et que vous l'avez compilé à partir de la source dactylographiée. Ensuite, vous pouvez activer l'indicateur --declarationMaps pour le compilateur dactylographié et les IDE qui prennent en charge les cartes de déclaration iront à la source dactylographiée au lieu des fichiers d.ts.

C'est vraiment crucial. Je veux une chose simple : CTLR+Cliquez et accédez au fichier node_modules/library/source.js ou source.ts. Projet opensource avec 60 dépendances node_modules et vous revenez à l'utilisation du bloc-notes avec l'explorateur.

Lorsque j'ai cliqué avec le bouton droit sur un composant, j'ai vu : "Aller à la définition" et "Aller à la définition du type". J'ai pensé "Super, cela a été bien conçu, la solution à mon problème est juste ici!". Ensuite, j'ai cliqué sur "Aller à la définition" et... j'ai atterri sur la définition de type.

C'est vraiment crucial. Je veux une chose simple : CTLR+Cliquez et accédez au fichier node_modules/library/source.js ou source.ts. Projet opensource avec 60 dépendances node_modules et vous revenez à l'utilisation du bloc-notes avec l'explorateur.

+1
Même besoin.

Avec tout le respect que je vous dois, le fait que cela ne soit pas mis en œuvre est incroyable. Un tel basique, relativement facile à
fonctionnalité de construction qui permettrait aux gens d'économiser des tonnes de temps.

Avec tout le respect que je vous dois, le fait que cela ne soit pas mis en œuvre est incroyable. Un tel basique, relativement facile à
fonctionnalité de construction qui permettrait aux gens d'économiser des tonnes de temps.

+1

Eh bien, en attendant, lorsque cette fonctionnalité n'est pas encore disponible, existe-t-il une meilleure solution de contournement à part la recherche de l'ensemble des node_modules ? C'est vraiment un inconvénient...
Par exemple, je vais à la définition et cela m'a amené à node_modules/@com.abc/sample/lib/core/internal/abc.d.ts alors que celui que je veux se situe en fait à node_modules/@com.abc/sample/src/core/internal/abc.ts

@Happin3ss

existe-t-il une meilleure solution de contournement en dehors de la recherche de l'ensemble des node_modules ?

La solution actuelle, autant que je sache, ce sont les cartes de déclaration . Ce sont des sourcesmaps qui mappent les fichiers .d.ts à la source TS correspondante. Si vous pouvez convaincre les bibliothèques dont vous dépendez d'implémenter des cartes de déclaration (ce qui, je pense, nécessite effectivement la publication de .d.ts dans le package de la bibliothèque au lieu de compter sur @types), vous pourrez alors sauter automatiquement à partir de votre code client au code source TS d'origine (ou même JS si vous utilisez le compilateur TS sur JS ?).

Ce que j'ai fait, c'est de déposer progressivement des PR contre mes dépendances les plus importantes (au moins celles qui sont créées dans TS) pour les amener à ajouter des cartes de déclaration.

Évidemment, ce serait mieux si le changement de bibliothèque n'était pas nécessaire.

Une autre solution de contournement (si la modification de la bibliothèque n'est pas possible) fonctionne dans le cas où la bibliothèque regroupe les fichiers .d.ts à l'intérieur du package mais n'a pas de mappes de déclaration. Dans ce cas, j'utiliserai Go To Definition pour accéder à la déclaration de type, puis je cliquerai sur le bouton Explorer dans VSCode pour afficher la barre latérale du dossier. Cela me rapproche généralement du dossier src du package, donc au lieu d'avoir à rechercher dans tous les node_modules, je peux simplement parcourir le bon dossier et ouvrir le bon fichier. Cela dépend d'un nom de fichier clair, etc. et n'est pas une panacée.

Juste pour être clair à 100% - j'aimerais voir une meilleure solution pour les bibliothèques, en particulier. ceux où .d.ts est créé séparément du package.

Je ne sais pas si je l'ai raté, mais il serait vraiment utile pour comprendre ce qui se passe d'avoir des exemples minimaux réels de sources, de déclarations et de cartes de déclaration. Je n'ai jamais vu Go to Definition, Go to Type Definition ou Go to Implémentations aller à autre chose qu'un fichier .d.ts pour TS transpilé. J'ai juste essayé de faire un exemple simple , et cela ne fonctionne pas ; Je n'arrive pas à obtenir que le code VS accède à autre chose que le fichier .d.ts , même si le .d.ts.map est à côté. J'ai également trouvé quelqu'un d'autre avec le même problème qui a été ignoré.

Il est compréhensible que la prise en charge des saisies externes comme @types soit difficile, mais qu'est-ce que cela signifie que même le « chemin heureux » ne peut pas fonctionner ?

Il existe de nombreuses bibliothèques qui génèrent des fichiers de déclaration mais pas de mappes de déclaration, et on ne sait pas quel serait l'argument pour les activer. Cette option a été ajoutée sans explication claire, au moins une que je pourrais trouver.

Oui, je confirme que les cartes de déclaration ne résolvent pas le problème. Mon projet a des cartes de déclaration mais vscode ne navigue pas au-delà des fichiers .d.ts.

Ce serait vraiment génial si cela arrivait.

s'il y a un "éléphant dans la pièce" de problèmes pour les développeurs ms vscode, c'est bien celui-ci.

Des mises à jour sur celui-ci?
J'ai juste décidé de faire un grand pas : passer de JS à TS. J'ai pensé - "qu'est-ce que je fais de mal ?" mais en fait, c'est un comportement inattendu de VSCode

Des mises à jour sur celui-ci?
J'ai juste décidé de faire un grand pas : passer de JS à TS. J'ai pensé - "qu'est-ce que je fais de mal ?" mais en fait, c'est un comportement inattendu de VSCode

Cela faisait longtemps que ce comportement n'avait pas été évoqué. Eh bien, il ne se passe rien ici. Aucun plan pour l'instant.
Pour moi, je continue à utiliser vscode comme une sorte d'éditeur, et les produits Intellij (IDEA) pour mes trucs de codage même si je ne l'aime pas tellement.

Ouvert depuis 5 ans, espérons qu'il sera réparé en 2025

J'ai créé des tests défaillants dans #39426 mais je ne sais pas comment l'implémenter

Juste un autre commentaire misérable de ts dev qui traverse l'enfer tous les jours pour trouver des définitions

C'est fou... Je pensais que j'étais juste un noob TS, mais maintenant je vois que le comportement que j'obtiens est en fait "standard" ???? Tellement frustrant, tous les autres IDE/langages que j'ai utilisés l'ont implémenté lors de la version initiale... :( J'adore le code VS mais honnêtement, cela pourrait être une rupture

Quelqu'un peut-il expliquer pourquoi les fonctionnalités go to definition/implementation dans VSCode avec des extensions Python pour, hein, le langage Python fonctionne mieux (ça marche au moins) que pour JS ayant des solutions natives intégrées ?

Alors, quoi de neuf?
J'utilise scss.d.ts pour les modules css et je ne peux pas passer à scss.

De plus, lors de la création de fichiers .js simples et, par conséquent, d.ts, je ne peux pas passer directement à js

pourquoi ne pas utiliser webstorm ?
ça peut résoudre ce problème !!!
ma version 2020.1

pourquoi ne pas utiliser webstorm ?
ça peut résoudre ce problème !!!
ma version 2020.1

Parce que ce n'est pas une solution open source et pas gratuite

Veuillez corriger cela.

Il est absolument clair que ce problème ne peut être résolu que si un responsable de Microsoft prend le relais, ce problème doit être géré et coordonné, un responsable développe un workflow et attribue le travail aux codeurs. ??
Ce problème doit être envoyé à la direction pour prendre en charge et ils décident comment il sera mis en œuvre.
Donc, s'il y a ici quelqu'un de compétent de Microsoft, il peut tenter sa chance. ??