Skip to content
Nx Docs

Multi-Language Support

Nx works with any language or toolchain. The task runner, caching, and affected commands all operate on the project graph. Plugins build that graph by reading existing configuration files, so adding support for a new language or tool means teaching Nx to read those existing files.

Basic configuration

Section titled “Basic configuration”

Nx doesn't need a plugin to run tasks for another language. Any directory with a project.json file is an Nx project, and its targets run any command with the same caching and orchestration as a JS task:

packages/py-api/project.json
{
  "name": "py-api",
  "targets": {
    "test": {
      "command": "uv run pytest",
      "options": { "cwd": "packages/py-api" },
      "cache": true,
      "inputs": ["{projectRoot}/**/*.py", "{workspaceRoot}/uv.lock"],
    },
  },
}

Automatically configure projects and tasks

Section titled “Automatically configure projects and tasks”

Plugins remove the need to write that configuration by hand. A language plugin declares which files mark a project, usually the toolchain's manifest: pyproject.toml for Python, go.mod for Go, Cargo.toml for Rust, build.gradle for Gradle. For every match, the plugin creates a project and its tasks, with caching, inputs, and outputs configured once in the plugin instead of per project. This is the same inferred tasks mechanism the JavaScript plugins use to read vite.config.ts or jest.config.ts.

Enabling a language plugin is one entry in nx.json:

nx.json
{
  "plugins": ["@nx/gradle", "@nx/dotnet"],
}

With these plugins enabled, the java-app and dotnet-app projects above no longer need a project.json. Their tasks are inferred from build.gradle and the .csproj file.

From there, Nx runs each toolchain's own commands, and cache hits restore outputs no matter what language produced them:

Terminal window
$ nx test py-api
> nx run py-api:test
12 passed in 1.2s
$ nx build rust-parser
> nx run rust-parser:build
Finished `release` profile [optimized] target(s) in 4.1s
$ nx test java-app
> nx run java-app:test
BUILD SUCCESSFUL in 6s
$ nx test dotnet-app
> nx run dotnet-app:test
Passed! - Failed: 0, Passed: 24, Total: 24

Run nx show project <project-name> to see everything a plugin inferred for a project.

Dependencies come from your toolchain

Section titled “Dependencies come from your toolchain”

Plugins also tell Nx how projects relate by reading the dependency information your toolchain already wrote down:

packages/py-api/pyproject.toml
[project]
name = "py-api"
dependencies = ["shared-utils"]


[tool.uv.sources]
shared-utils = { workspace = true }

Manifests aren't the only source. The built-in JavaScript and TypeScript support parses source files and creates dependencies from import statements, in addition to package.json dependencies, and a plugin can do the same for its own language.

These edges are what make nx affected, task ordering, and the graph visualization accurate across languages, and they connect cross-language boundaries too, such as a deploy task that depends on both a JS frontend and a Java backend.

Use an existing plugin

Section titled “Use an existing plugin”

Check what already covers your toolchain before writing a plugin:

Browse the plugin registry for the full list.

Build your own plugin

Section titled “Build your own plugin”

If your toolchain isn't covered, you can add your own support with a plugin. Follow add language support to Nx for a complete walkthrough that uses Python with uv and adapts to any toolchain.