Know Exactly What Coroid Supports
This matrix is the clearest view of current support across language servers, build flows, test runners, and containerized verification. Where setup is required, we say so directly.
Current Compatibility
Use this as the working contract for what Coroid can inspect, build, and verify today.
TypeScript / JavaScript
- Strongest end-to-end support today, including LSP, builds, and browser-driven verification.
Mobile TypeScript
- Expo and React Native projects are supported through the TypeScript/Node toolchain. Type-checking and Jest tests are verifiable locally; native simulator, device, and store builds require platform setup.
Python
- Python LSP support is available; framework-specific runtime flows are strongest for Django, Flask, and FastAPI.
Java
- Java now supports LSP and Maven-based container flows. Gradle and private artifacts are best treated as partial support with explicit setup.
.NET / C#
- .NET supports LSP, restore/build flows, and ASP.NET-oriented Docker startup. Non-web projects are more limited for runtime verification.
Go
- Go builds and container startup are straightforward. Rich semantic language-server support is not yet first-class.
PHP
- Framework-specific Docker startup exists for Laravel and Symfony, but semantic tooling and broader verification remain partial.
Ruby
- Rails projects can be started in Docker, but language-server and deeper build/test coverage are still limited.
Extra Setup You May Need
Private package feeds need explicit credentials
Private Maven and NuGet dependencies work when repository credentials or full config payloads are injected into the runner environment. Coroid does not guess private feed auth.
Bootstrap hooks are available for repo-specific setup
If a repo needs custom prep before restore or build, Coroid can run bootstrap scripts or commands before the standard install/build/start chain.
Java support is best with wrappers or standard Maven projects
Maven is supported directly, and wrapper-based repos remain the safest path. Gradle support is strongest when the wrapper is committed.
.NET runtime verification depends on a clear web entrypoint
ASP.NET Core projects with a clear runnable project file are the best fit for containerized runtime verification.
Mobile native builds require platform tooling
Expo TypeScript code can be type-checked and tested without emulators. iOS simulator/device builds require macOS and Xcode; Android builds require the Android SDK or an Expo-compatible runner.
Works Best When
- Your repo commits standard wrappers like mvnw or gradlew where relevant.
- Dependency lockfiles and manifest files are checked in and current.
- Private feed credentials are injected as environment variables instead of hidden in local machine config.
- Any one-off restore or codegen steps are captured in a bootstrap script instead of tribal knowledge.
Compatibility is strongest when repositories include standard wrappers, lockfiles, clear entrypoints, and explicit credentials for private dependencies.