Version-matched language servers

Follow the project’s Slint version#

The plugin reads exact versions from lockfiles including Cargo, npm/pnpm/Yarn, uv, and Poetry. Without a lock it checks host manifests, then uses its tested default. This is why two projects in the same IDE can legitimately start different managed server versions.

Open Settings → Languages & Frameworks → Slint and compare the selected binary and version with the project’s dependency. Do not override detection merely to use a newer server if the application is pinned to older Slint syntax.

Managed server#

A managed release is downloaded on first use, verified against its published digest, extracted, and cached in the IDE system area. Projects using the same version can share it. Startup needs network access only when the required assets are absent.

For a diagnostic exercise, open a valid .slint file and use completion on a built-in property. Inspect the LSP4IJ console if no server-backed candidates or compiler diagnostics arrive.

External server#

Select an external executable for an offline/private toolchain. Confirm its actual version with slint-lsp --version and configure a full path when the desktop IDE cannot find your shell installation. Restart after changing it.

Preview runtime is another asset#

A running language server does not guarantee that the integrated Designer runtime exists for that exact version. Designer WASM can come from the VS Code extension or GitHub web release; an unavailable compatible runtime falls back to native preview. Read the setup banner to distinguish a missing JCEF runtime, failed server, and unavailable Designer asset.

Compiler diagnostics remain authoritative for the selected project version. Native inspections supplement them with local structure, imports, paths, and portability checks.