OpenCode LSP : rôle, activation et correction des serveurs désactivés

LSP signifie Language Server Protocol. Un serveur de langage fonctionne à côté du projet et fournit diagnostics, symboles, définitions, références et informations de survol. OpenCode peut utiliser ces données pendant une session au lieu de considérer chaque fichier comme du texte isolé.

L’intérêt concret est le contexte. Si le serveur TypeScript comprend une importation, l’agent dispose de meilleures preuves pour expliquer une erreur de type ou un renommage. Cela ne garantit pas une réponse juste : le serveur peut manquer, le projet peut mal se charger ou le paquet peut demander sa propre configuration. LSP enrichit le contexte, mais ne remplace ni les tests ni la revue du diff.

Une entrée LSP demande une commande exécutable et un lien clair avec les extensions. La commande démarre le serveur et la liste d’extensions indique les fichiers concernés. L’exécutable, les arguments et l’installation dépendent de la documentation du serveur ; ne devinez pas un paquet.

Commencez avec un langage dans un petit dépôt. Ouvrez un fichier correspondant, vérifiez que le processus démarre, puis demandez une lecture seule. Une extension mal associée peut faire paraître un serveur valide défaillant, car OpenCode ne l’attache pas au fichier.

Placez les décisions communes dans une configuration de projet relue. Gardez les essais personnels dans la configuration globale jusqu’à ce que la commande, les extensions et la racine soient claires. La documentation JSONC traite la portée et le Schema ; cette page reste centrée sur le serveur de langage.

Une petite entrée est plus facile à diagnostiquer qu’un grand catalogue. Utilisez un nom descriptif, un tableau de commandes explicite et les seules extensions supportées. Ajoutez les options d’initialisation après le démarrage de base. Un JSON valide ne prouve pas que l’exécutable ou le workspace est correct.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "typescript": {
      "command": ["typescript-language-server", "--stdio"],
      "extensions": [".ts", ".tsx"]
    }
  }
}

La documentation officielle actuelle indique que l’absence de lsp désactive tous les serveurs. Pour tout couper après une autre configuration, utilisez lsp: false; pour un serveur précis, disabled: true. C’est utile si le serveur est lent, bruyant ou incompatible avec un dépôt.

Les serveurs personnalisés couvrent les langages ou extensions absents de la configuration courante. Définissez d’abord commande et extensions, ajoutez l’initialisation selon la documentation, puis modifiez une seule chose à la fois. Conservez la dernière configuration fonctionnelle pour revenir en arrière.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": false
}

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "custom-lsp": {
      "command": ["custom-lsp-server", "--stdio"],
      "extensions": [".custom"],
      "initialization": { "preferences": { "mode": "strict" } }
    }
  }
}

Ne commencez pas par réécrire un module entier. Utilisez un dépôt propre, ouvrez un fichier connu et demandez une lecture seule : symbole, définition ou diagnostic. Comparez le résultat avec l’éditeur, le compilateur ou le serveur déjà fiable.

Après cette vérification, faites une petite modification réversible et inspectez le diff. Notez le système, la commande, les extensions, la racine et le prompt. Cette note rend l’installation reproductible et facilite le prochain diagnostic.

1. NettoyerPartir d’une branche et d’un arbre de travail connus.
2. AssocierOuvrir une extension déclarée par le serveur.
3. LireDemander symbole, définition, référence ou diagnostic.
4. ModifierFaire un petit changement réversible et voir le diff.
5. NoterConserver commande, modèle, serveur et rollback.

Si OpenCode dit que les LSP sont désactivés, vérifiez la priorité des configurations avant de réinstaller. Un autre fichier peut imposer lsp: false, le projet peut oublier le serveur ou une entrée peut contenir disabled. Comparez le dossier réel du projet à l’emplacement du fichier gagnant.

Si le serveur est actif mais ne donne aucun diagnostic, vérifiez ensuite commande et extension. Lancez-le dans le même shell si possible, contrôlez runtime et PATH, et voyez si le projet exige lockfile, configuration de compilateur ou racine de workspace. Un premier résultat lent peut simplement correspondre à l’indexation.

Gardez les permissions étroites. LSP demande un processus et un contexte de projet, pas un shell illimité, davantage de MCP ou l’auto-approbation. Utilisez les pages sur les permissions et MCP si le problème change de couche.

LSP apporte l’intelligence de langage au dépôt. MCP connecte outils et données externes. Le formateur modifie le style et les tests apportent une preuve exécutable. VS Code peut afficher ses propres diagnostics ; cela ne prouve pas qu’OpenCode utilise le même serveur ou la même racine.

Utilisez la page adaptée : MCP traite les serveurs locaux et distants, VS Code le contexte de l’éditeur et du terminal, et permissions les validations. Cette séparation garde la page LSP dans OpenCode ciblée.