Language server

The language server provides hover information with inferred types, completion with automatic imports, go to definition, find references, scope-aware rename, document and workspace symbols, document highlights, semantic highlighting, typed-hole suggestions, and diagnostics.

Watch each feature in Visual Studio Code on the home page.

Install the Iris extension from the Visual Studio Marketplace. It starts the language server with the iris executable on your PATH. To use a particular executable instead, set iris.client.serverPath.

Configure your editor’s LSP client to start iris lsp --stdio for PureScript files. The lsp subcommand is required: iris alone no longer starts the server, and language-server options must follow lsp.

Run iris lsp --help to see the available options.

Editors that advertise the LSP workspace.configuration capability can provide settings in the iris.server configuration section. All settings are optional. The defaults are:

{  "diagnostics": {    "onOpen": true,    "onSave": true,    "onChange": false  }}

The diagnostic settings publish diagnostics when a document opens, when it’s saved, and as it changes before saving. They control those document-event triggers, not all diagnostic publishing.

In Visual Studio Code, these are the iris.server.diagnostics.onOpen, iris.server.diagnostics.onSave, and iris.server.diagnostics.onChange settings.

Use the configuration JSON Schema for editor validation. Associate it through your editor’s settings rather than adding a $schema property.

Iris requests the iris.server section for the first workspace folder after initialization, and again after each workspace/didChangeConfiguration notification. The notification’s settings value is only an invalidation signal.

Each response is a complete configuration. Missing or null fields take their defaults rather than values from the preceding response, and {} or a top-level null selects every default.

Unknown fields and invalid values are shown in the editor, and an invalid update leaves the last valid configuration active. Clients without workspace-configuration support use the defaults.

Iris prepares the Spago workspace during startup, before serving analysis. It runs spago fetch in the workspace root, then discovers sources from spago.yaml and package manifests, using the resolution written by that fetch to select fetched .spago checkouts exactly.

To find Spago, Iris uses the executable named by IRIS_SPAGO, then <workspace root>/node_modules/.bin, then your PATH.

Preparation runs off the protocol loop, so the server keeps accepting document notifications and replays them in order once the workspace is ready. Requests made before preparation completes are rejected with ContentModified and the message Workspace is loading, so clients that retry stale requests can try again.

If preparation fails, Iris reports the failure in the editor and doesn’t serve analysis from the partially installed project. Correct the project, for example by running spago fetch, then restart Iris. Iris doesn’t retry preparation automatically.