Matrice de prise en charge

Savoir précisément Ce que Coroid prend en charge

Cette matrice offre la vue la plus claire de la prise en charge actuelle des serveurs de langage, des flux de build, des exécuteurs de tests et de la vérification conteneurisée. Lorsqu'une configuration est requise, nous l'indiquons clairement.

LSP
5
Langages actuellement pris en charge
Build
4
Langages actuellement pris en charge
Docker
8
Langages actuellement pris en charge

Compatibilité actuelle

Utilisez ceci comme contrat de travail définissant ce que Coroid peut inspecter, construire et vérifier aujourd'hui.

Prise en chargePartielleConfiguration requisePrévu

TypeScript / JavaScript

Next.jsReactViteNode.js
  • La prise en charge complète de bout en bout est aujourd'hui la plus solide, y compris le LSP, les builds et la vérification pilotée par le navigateur.
LSP
Prise en charge
Build
Prise en charge
Test
Prise en charge
Docker
Prise en charge

TypeScript mobile

ExpoReact NativeLogique d'application TypeScript
  • Les projets Expo et React Native sont pris en charge via l'outilchain TypeScript/Node. La vérification de type et les tests Jest peuvent être effectués localement ; les builds pour simulateur natif, appareil et boutique nécessitent une configuration spécifique à la plateforme.
LSP
Prise en charge
Build
Partielle
Test
Prise en charge
Docker
Partielle

Python

DjangoFlaskFastAPIrequirements.txt / pyproject
  • La prise en charge du LSP Python est disponible ; les flux d'exécution propres au framework sont les plus performants pour Django, Flask et FastAPI.
LSP
Prise en charge
Build
Partielle
Test
Partielle
Docker
Prise en charge

Java

Spring BootQuarkusMicronautMavenGradle
  • Java prend désormais en charge le LSP et les flux de conteneurs basés sur Maven. Gradle et les artefacts privés nécessitent une configuration explicite pour une prise en charge partielle.
LSP
Prise en charge
Build
Prise en charge
Test
Partielle
Docker
Partielle

.NET / C#

ASP.NET CoreCLI dotnetNuGet.sln / .csproj
  • .NET prend en charge le LSP, les flux de restauration/build et le démarrage Docker orienté ASP.NET. Les projets non web présentent des limites plus importantes pour la vérification à l'exécution.
LSP
Prise en charge
Build
Prise en charge
Test
Partielle
Docker
Partielle

Go

Gin / Go HTTPgo.mod
  • Les builds Go et le démarrage des conteneurs sont simples. La prise en charge approfondie du serveur de langage sémantique n'est pas encore optimale.
LSP
Prévu
Build
Prise en charge
Test
Partielle
Docker
Prise en charge

PHP

LaravelSymfonyComposer
  • Le démarrage Docker propre au framework existe pour Laravel et Symfony, mais les outils sémantiques et la vérification globale restent partiels.
LSP
Prévu
Build
Partielle
Test
Partielle
Docker
Prise en charge

Ruby

RailsBundler
  • Les projets Rails peuvent être démarrés dans Docker, mais la couverture du serveur de langage et des builds/tests plus poussés reste limitée.
LSP
Prévu
Build
Partielle
Test
Partielle
Docker
Prise en charge

Configuration supplémentaire éventuellement nécessaire

Les flux de packages privés nécessitent des identifiants explicites

Les dépendances Maven et NuGet privées fonctionnent lorsque les identifiants du dépôt ou les charges utiles de configuration complètes sont injectés dans l'environnement d'exécution. Coroid ne devine pas les informations d'authentification des flux privés.

Des hooks de démarrage sont disponibles pour la configuration spécifique aux dépôts

Si un dépôt nécessite une préparation personnalisée avant la restauration ou la compilation, Coroid peut exécuter des scripts ou des commandes de démarrage avant la chaîne standard d'installation/compilation/démarrage.

La prise en charge de Java est optimale avec des wrappers ou des projets Maven standards

Maven est directement pris en charge, et les dépôts utilisant des wrappers constituent la solution la plus fiable. La prise en charge de Gradle est la plus efficace lorsque le wrapper est inclus dans le commit.

La vérification du runtime .NET dépend d'un point d'entrée web bien défini

Les projets ASP.NET Core dotés d'un fichier de projet exécutable clair conviennent le mieux à la vérification du runtime conteneurisé.

Les builds natifs mobiles requièrent des outils de plateforme spécifiques

Le code Expo TypeScript peut être vérifié et testé sans émulateur. Les builds pour simulateur/appareil iOS nécessitent macOS et Xcode ; les builds Android requièrent l'Android SDK ou un environnement d'exécution compatible avec Expo.

Meilleurs résultats lorsque

  • Votre dépôt utilise des wrappers standards comme mvnw ou gradlew lorsque c’est pertinent.
  • Les fichiers de verrouillage des dépendances et les fichiers de manifeste sont présents et à jour.
  • Les identifiants des flux privés sont injectés en tant que variables d'environnement plutôt que d'être cachés dans la configuration locale de la machine.
  • Toutes les étapes ponctuelles de restauration ou de génération de code sont capturées dans un script de démarrage plutôt que de reposer sur des connaissances tacites.

La compatibilité est optimale lorsque les dépôts incluent des wrappers standards, des fichiers de verrouillage, des points d'entrée clairs et des identifiants explicites pour les dépendances privées.