Comment interroger le code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

# Comment interroger le code

Ce guide montre comment suivre un nom dans un fichier JavaScript : ce que c'est, où il est déclaré, ce que déclare le fichier, et ce qui ne va pas. Il suppose Turbo JS installé et un serveur de langage en marche — la barre d'état affiche `LSP: ready` quand c'est le cas.

Pour se déplacer dans un fichier — chercher, aller à une ligne, changer de fenêtre — voir plutôt [Comment se déplacer dans un fichier](navigate-code.md).

## Placez le curseur sur un nom

N'importe lequel de ses caractères suffit. Chaque question ci-dessous porte sur la **position du curseur**, pas sur une sélection : il n'y a rien à surligner d'abord.

## Demandez

| Pour trouver | Faites | Raccourci |
| --- | --- | --- |
| Ce que c'est | **Code ▸ Describe symbol** | `F1` |
| Où c'est déclaré | **Code ▸ Go to definition** | `F12` |
| Où son *type* est déclaré | **Code ▸ Go to type definition** | |
| Ce qui l'implémente | **Code ▸ Find implementations…** | |
| Partout où c'est utilisé | **Code ▸ Find references…** | `Shift-F12` |

**Les cinq entrées répondent avec `typescript-language-server`.** Le serveur — un programme séparé, `typescript-language-server --stdio`, installé par `npm install -g typescript-language-server typescript@6` — annonce `typeDefinition`, `implementation` et `references` comme le reste : **Go to type definition** sur `const shape = new Circle()` mène à la classe `Circle`, **Find implementations** sur une classe liste ses sous-classes, et **Find references** donne la déclaration et chaque appel. Voir [coloration et complétion](../explanation/colouring-and-completion.md) pour ce que l'éditeur demande, et pourquoi.

Le serveur est démarré à la **racine du projet** — le dossier du `package.json` le plus proche du fichier ouvert, ou le dossier courant s'il n'y en a aucun — et c'est ce projet qu'il connaît.

**Describe symbol** sur une fonction que vous avez déclarée montre sa signature et le commentaire JSDoc — `/** … */` — écrit juste au-dessus d'elle : c'est là qu'il faut documenter.

Une seule réponse vous y emmène directement. Plusieurs ouvrent une liste montrant le fichier, sa ligne, et le texte de cette ligne ; déplacez-vous aux flèches, `Entrée` pour y aller, `Échap` pour rester.

## Quand rien ne revient

Trois choses se ressemblent, et la barre d'état les distingue :

| Elle affiche | Signification |
| --- | --- |
| `No references found`, ou l'équivalent pour la question posée | Le serveur a répondu, et il n'y en a pas |
| Autre chose, par exemple `LSP: starting…` | Le serveur n'est pas encore prêt. Attendez un instant et redemandez. |
| `LSP: off` dans la barre d'état | Aucun serveur ne tourne. Voir [Comment activer la complétion](enable-completion.md). |

La deuxième mérite d'être connue : un serveur qui démarre encore répond rien à toutes les questions, et c'est indiscernable d'une vraie réponse si l'éditeur ne le dit pas.

## Chercher par le nom

- **Code ▸ Symbol in file…** liste ce que déclare le fichier devant vous, indenté, avec la sorte de chaque symbole — un plan que l'on parcourt. Pour du JavaScript : les fonctions et les classes du fichier.
- **Code ▸ Symbol in project…** (`Ctrl-T`) demande un nom et cherche partout dans le projet. Ce qui compte comme correspondance appartient au serveur.

## Voir ce qui ne va pas

**Code ▸ Problems…** liste tous les problèmes signalés par le serveur, pour **tous les fichiers qu'il a chargés** — le plus souvent davantage que celui que vous éditez. En choisir un vous mène à la ligne.

`typescript-language-server` publie ses diagnostics à l'ouverture d'un fichier et à chaque modification, sans qu'on lui demande. Pour un fichier `.js` ordinaire, ce sont les **erreurs de syntaxe** de son analyseur — un `function main( {` reçoit sa marque, et la barre d'état affiche le message derrière un `⚠`. Les erreurs de type demandent `// @ts-check` en tête du fichier, ou `checkJs` dans un `jsconfig.json` ; sans l'un ni l'autre, une faute de type ne reçoit aucune marque.

Les lignes à problème portent une marque dans la gouttière, à côté du numéro de ligne :

| Marque | Signification |
| --- | --- |
| `×` | Une erreur |
| `!` | Un avertissement |
| `i` | Une information |
| `·` | Une suggestion |

Une ligne qui a plusieurs problèmes montre le pire d'entre eux.

**Les marques ont besoin des numéros de ligne.** Elles occupent la colonne qui sépare les numéros du texte : masquer la gouttière avec **Options ▸ Line numbers** les masque aussi.

## Voir aussi

- Chaque entrée et sa touche : [Menus](../reference/menus.md)
- Faire tourner un serveur : [Comment activer la complétion](enable-completion.md)
- Ce que l'éditeur demande, et pourquoi : [Coloration et complétion](../explanation/colouring-and-completion.md)
- Ce que `typescript-language-server` sait et ne sait pas répondre : [Outils JavaScript](../explanation/javascript-tools.md)