Exporter les métadonnées d'un Language Server dans une base SQL

Le problème des requêtes JSON-RPC en direct

Les serveurs de langage utilisant le protocole LSP (Language Server Protocol, standard de communication entre éditeurs de code et outils d'analyse linguistique) contiennent une quantité impressionnante d'informations structurelles sur votre code source : types, symboles, emplacements et dépendances. Cependant, interroger directement ces serveurs reste complexe en raison de leur mode de communication fondé sur le protocole JSON-RPC (JSON Remote Procedure Call, un protocole d'appel distant au format texte). Pour exploiter ces métadonnées d'analyse statique à des fins d'inspection globale, une approche efficace consiste à les extraire pour les charger dans une base de données SQL (Structured Query Language).

Le fonctionnement sous le capot du protocole LSP

Un serveur de langage s'exécute généralement sous la forme d'un processus séparé, piloté par l'environnement de développement via les flux stdin et stdout (les flux standards d'entrée et de sortie des processus). La communication est basée sur un échange orienté état : il faut d'abord notifier le serveur de l'ouverture d'un fichier avec la méthode textDocument/didOpen avant de pouvoir effectuer des requêtes de recherche de symboles ou d'annotations de survol. Chaque message transporte un en-tête Content-Length suivi de séparateurs de lignes \r\n\r\n et du corps de données JSON (JavaScript Object Notation).

Du script Bash bancale à la base de données SQL

Tester ces appels en ligne de commande via des outils comme Bash ou jq (processeur de données JSON en ligne de commande) s'avère vite laborieux. La gestion asynchrone des flux d'écriture du moteur Node.js impose parfois des temporisations artificielles avec l'instruction sleep pour éviter que le processus ne se termine prématurément avant de recevoir la réponse. Pour contourner cette fragilité, un script écrit en Python permet d'orchestrer le serveur typescript-language-server (l'adaptateur LSP du compilateur TypeScript) afin d'extraire les symboles de manière fiable et de les insérer dans DuckDB (une base de données SQL relationnelle orientée colonnes et optimisée pour l'analyse).

Interroger le code source avec des requêtes SQL

Une fois les données ingérées dans la base, l'analyse d'un projet volumineux comme la bibliothèque web Hono (un cadre d'application web léger pour JavaScript et TypeScript) devient immédiate. Au lieu de manipuler des réponses JSON imbriquées, une simple requête SQL permet d'inspecter les constantes, fonctions et variables définies dans un fichier :

duckdb language-server-db/sample/hono.db --line \
  "SELECT * FROM symbols WHERE uri LIKE '%url.ts' ORDER BY symbol_start_line DESC LIMIT 1"

Cette commande retourne un enregistrement structuré exploitable directement par d'autres scripts d'ingénierie :

uri = file:///Users/philip/src/hono/src/utils/url.ts
symbol_name = decodeURIComponent_
symbol_kind = Constant
symbol_start_line = 309
symbol_start_character = 13

Un nouvel outil pour l'analyse statique

Rendre visibles ces données jusqu'ici enfouies au cœur de l'éditeur offre des perspectives concrètes : cartographie de bases de code, audit de conformité de types ou génération de documentation technique. En basculant du modèle interactif de l'environnement de développement vers un schéma SQL interrogeable, l'exploration de la structure d'un projet devient un simple exercice de requêtage.