Documentation

Language and framework support

How deeply Coroid supports each language, and what the status labels actually mean.

Coroid's support varies by language. The live matrix is on the compatibility page; this page explains how to read it.

The four capabilities

Support is tracked per language across four axes, because a language can be well-supported on one and weak on another.

CapabilityWhat it means
Language serverSemantic understanding — go to definition, find references, types
BuildCoroid can compile or package the project
TestCoroid can run the suite and interpret results
ContainerThe project can run in a container

The language server axis is the one that most affects quality. With it, an agent can ask precise questions about your code — what calls this, what type is this — instead of inferring from text. Without it, the agent falls back to reading, which works but is less reliable on large codebases.

The status labels

Supported — works without special setup.

Partial — works, with a named gap. Read the detail; a partial status on the container axis means something very different from a partial status on tests.

Setup required — works once you configure it by hand. Detection will not get there on its own, but there is nothing structurally missing.

Planned — not available. Treat it as absent, not imminent.

Languages covered

TypeScript and JavaScript, Python, Java, .NET, Go, PHP and Ruby, each with its own profile across the four axes.

Mixed-language projects

Most real projects are more than one language. Coroid handles this — a TypeScript frontend with a Python service is ordinary — but depth follows the weakest language in the part being changed.

If most of your work happens in a well-supported language and a small part does not, that is usually fine. If the reverse is true, expect more hand-configuration.

When your language is weakly supported

The practical fallbacks:

  • Configure build and test commands explicitly rather than relying on detection. See Build and test configuration.
  • Containerise. A working container removes most environment-level gaps.
  • Invest more in project context, which partly compensates for what a missing language server would have provided.