Erfahren Sie genau, was Coroid unterstützt.
Diese Matrix bietet den klaren Überblick über die aktuelle Unterstützung für Sprachserver, Build-Prozesse, Test-Runner und containerisierte Verifizierung. Wo eine Einrichtung erforderlich ist, weisen wir explizit darauf hin.
- LSP
- 5
- Sprachen mit aktueller Unterstützung
- Build
- 4
- Sprachen mit aktueller Unterstützung
- Docker
- 8
- Sprachen mit aktueller Unterstützung
Aktuelle Kompatibilität
Nutzen Sie dies als verbindlichen Vertrag dafür, was Coroid heute inspizieren, erstellen und verifizieren kann.
TypeScript / JavaScript
- Heute die umfassendste End-to-End-Unterstützung – einschließlich LSP, Builds und browserbasierter Verifizierung.
Mobile TypeScript
- Expo- und React-Native-Projekte werden über das TypeScript/Node-Toolchain unterstützt. Typüberprüfungen und Jest-Tests lassen sich lokal verifizieren; für native Simulatoren, Geräte und Store-Builds ist eine Plattformkonfiguration erforderlich.
Python
- Python-LSP-Unterstützung ist verfügbar; für Django, Flask und FastAPI sind framework-spezifische Laufzeitabläufe am besten geeignet.
Java
- Java unterstützt nun LSP und Maven-basierte Container-Abläufe. Gradle und private Artefakte gelten als teilweise unterstützt und erfordern eine explizite Einrichtung.
.NET / C#
- .NET bietet LSP-Unterstützung, Restore-/Build-Abläufe sowie Docker-Start für ASP.NET-Anwendungen. Nicht-webbasierte Projekte weisen bei der Laufzeitverifizierung stärkere Einschränkungen auf.
Go
- Go-Builds und Container-Startvorgänge sind unkompliziert. Eine umfassende Unterstützung durch Sprachserver steht noch nicht zur Verfügung.
PHP
- Für Laravel und Symfony existiert eine Docker-Startunterstützung auf Framework-Ebene; semantische Tools und eine breitere Verifizierung bleiben jedoch teilweise eingeschränkt.
Ruby
- Rails-Projekte lassen sich in Docker starten; Sprachserver- und tiefgreifendere Build-/Test-Funktionen sind jedoch noch begrenzt.
Zusätzliche Einrichtung, die möglicherweise erforderlich ist
Für private Paketfeeds sind explizite Anmeldeinformationen erforderlich.
Private Maven- und NuGet-Abhängigkeiten funktionieren, sobald Repository-Anmeldeinformationen oder vollständige Konfigurationspakete in die Runner-Umgebung eingespielt werden. Coroid rät nicht bei der Authentifizierung für private Feeds.
Bootstrap-Hooks stehen für repo-spezifische Einrichtungen zur Verfügung.
Falls ein Repository vor dem Restore oder Build eine individuelle Vorbereitung benötigt, kann Coroid Skripte oder Befehle zum Bootstrap vor der Standard-Install-/Build-/Start-Kette ausführen.
Die Java-Unterstützung ist mit Wrappern oder Standard-Maven-Projekten am besten.
Maven wird direkt unterstützt, und Repositories mit Wrapper stellen den sichersten Weg dar. Die Gradle-Unterstützung ist am stabilsten, wenn der Wrapper committet wird.
Die Überprüfung der .NET-Laufzeit hängt von einem klar definierten Web-Einstiegspunkt ab.
ASP.NET Core-Projekte mit einer klar ausführbaren Projektdatei eignen sich am besten für die Überprüfung der containerisierten Laufzeit.
Native mobile Builds erfordern plattformbezogene Tools.
Expo TypeScript-Code kann ohne Emulatoren auf Typfehler überprüft und getestet werden. Für iOS-Simulator-/Geräte-Builds sind macOS und Xcode erforderlich; Android-Builds benötigen das Android SDK oder einen mit Expo kompatiblen Runner.
Funktioniert am besten, wenn
- Ihr Repository verwendet relevante Standard-Wrapper wie mvnw oder gradlew.
- Abhängigkeits-Lockfiles und Manifest-Dateien sind eingecheckt und aktuell.
- Anmeldeinformationen für private Feeds werden als Umgebungsvariablen eingefügt – nicht in lokalen Maschinen-Konfigurationen versteckt.
- Einmalige Restore- oder Codegen-Schritte werden in einem Bootstrap-Skript festgehalten – nicht als implizites Wissen weitergegeben.
Die Kompatibilität ist am stärksten, wenn Repositorys Standard-Wrapper, Lockfiles, klare Einstiegspunkte und explizite Zugangsdaten für private Abhängigkeiten enthalten.