Documentation / L’IDE
Serveurs de langage et build
Les serveurs de langage que Yuli installe et maintient pour vous, sans npm ni Node sur le système, et les adaptateurs de build pour Python, Go, .NET, sbt, Bazel et Node.
Pour chaque langage, Yuli utilise le serveur de langage (LSP) de référence et le gère pour vous : il le télécharge avec votre autorisation, le vérifie et le garde hors de vos projets. Java dispose de son propre moteur natif, et CSS, SCSS et LESS sont pris en charge par l’éditeur.
Serveurs gérés
| Langage | Serveur | Installé depuis |
|---|---|---|
| TypeScript et JavaScript | typescript-language-server avec typescript (le vrai tsserver) |
Registre npm |
| Python | Pyright | Registre npm |
| Go | gopls | go install |
| Kotlin | kotlin-language-server | Zip GitHub |
| C# | csharp-ls | dotnet tool |
| PHP | Intelephense | Registre npm |
| Ruby | ruby-lsp | gem |
| C et C++ | clangd 19.1.2 | Zip GitHub |
| Bash | bash-language-server | Registre npm |
| Dockerfile | dockerfile-language-server-nodejs | Registre npm |
| Rust | rust-analyzer | Binaire GitHub |
Sans npm ni Node sur votre machine
- Les paquets sont téléchargés directement depuis le registre npm et vérifiés par rapport à la somme SHA-512 publiée par le registre.
- Aucun script d’installation ni aucune dépendance facultative n’est exécuté.
- Ils tournent sur l’Electron de Yuli en mode Node, ou sur un Node téléchargé par Yuli. Vous n’avez pas besoin d’avoir npm ni Node installés.
- Ils sont stockés dans
<runtimes>/<serveur>/<version>/. - Un téléchargement n’est interrompu que si plus aucune donnée n’arrive pendant 60 secondes ; un téléchargement lent mais actif n’est pas coupé.
Le dossier des runtimes de Yuli (<runtimes>) dépend du système :
%LOCALAPPDATA%\.yulicode\runtimes
~/Library/Caches/.yulicode/runtimes
$XDG_CACHE_HOME/yulicode/runtimes (par défaut, ~/.cache/yulicode/runtimes)
Avec votre autorisation
S’il manque le serveur d’un langage, l’éditeur affiche « Aucun serveur de langage pour… » avec ces options :
| Option | Rôle |
|---|---|
| Autoriser le téléchargement / Autoriser l’installation | Yuli l’installe et le démarre |
| Pas maintenant | Ne redemande plus pendant cette session |
| Ne plus demander | Mémorise votre décision pour ce serveur |
Rien ne sera téléchargé ni exécuté sans votre autorisation. Les décisions sont enregistrées dans lsp-install-consent.json, à côté de votre configuration, par serveur et par cible (cette machine ou un hôte distant).
Dans Options globales → Serveurs de langage, vous pouvez indiquer le chemin d’un serveur que vous avez déjà, ou une URL ou un miroir de confiance.
Adaptateurs de build
Yuli détecte comment chaque projet se construit à partir de ses fichiers, sans rien exécuter pour le savoir, et utilise ces outils pour compiler, exécuter, tester et afficher les résultats dans le panneau Tests.
- Gestionnaires : pip (
requirements*.txt,setup.pyou unpyproject.tomlsimple), Poetry, uv, Pipenv et Hatch. - Environnement : utilise l’environnement virtuel du projet (
.venv/venv, les dossiers de Poetry et de Pipenv ou celui de Hatch). Sans environnement, il utilise lerundu gestionnaire et, à défaut, le Python du système. - Tests : pytest si le projet le configure ou en dépend ; sinon, unittest.
- Le même environnement est transmis à Pyright, ce qui permet à la saisie semi-automatique de voir vos dépendances.
go build,go runetgo test ./....- Les tests sont lus au format
-jsonpour l’explorateur de tests, et la console affiche le texte comme avec-v.
- Projets
.sln,.csproj,.fsprojet.vbproj. - Les résultats des tests arrivent au format TRX.
- Projets avec
build.sbt. - Les résultats des tests sont lus depuis le JUnit XML de
target/test-reports.
- Projets avec
MODULE.bazelouWORKSPACE. bazel build //...,bazel test //...etbazel run <cible>; utilise bazelisk s’il est installé.
- Gestionnaire de paquets : le champ
packageManagerdupackage.jsonet, à défaut, le lockfile :pnpm-lock.yaml,yarn.lock,bun.lockboupackage-lock.json. - Couverture : avec l’outil que le projet possède déjà, dans cet ordre : vitest, jest, c8 et nyc. Yuli lit
coverage/coverage-summary.json. Sans aucun d’eux, pas de couverture.
Maven, Gradle, Ant et Cargo fonctionnent comme toujours ; voir Exécuter et déboguer.
▶ dans la marge
À côté du code apparaît un ▶ pour exécuter ou déboguer ce que vous avez sous les yeux. Il n’est affiché que lorsque le projet est réellement de ce type.
| Langage | Exécuter | Déboguer |
|---|---|---|
| Python | if __name__ == "__main__": et tests pytest ou unittest |
if __name__ == "__main__": |
| Go | func main et func TestX |
func main et func TestX |
| C# | Tests xUnit, NUnit et MSTest | static void Main( |
De plus, dans un package.json, chaque script a son ▶ (il s’exécute avec le gestionnaire du projet), et en Java il y a un ▶ pour les classes avec main, les tests et les tâches Maven et Gradle.
Voir Débogage pour les sessions de débogage et Éditeur et langages pour le reste de l’éditeur.