@tabnas/lsp

The tabnas language server and language-server generator.

One LSP server serves every tabnas grammar — fleet plugins, serialized GrammarSpec data, or BNF-dialect text added dynamically through workspace configuration — and the same machinery generates standalone single-language servers (Node packages or Go binaries) plus the editor plugins to use them, from one parser module or grammar.

# the unified server, over stdio
npx --package=@tabnas/lsp tabnas-lsp --stdio

# a branded single-language server + editor plugins
npx --package=@tabnas/lsp tabnas-lsp-gen \
  --spec my-grammar.json --language-id mydsl --out mydsl-tools

--package is required either way: this package ships two binaries and neither is named @tabnas/lsp, so the package-name form of npx cannot pick one, and a bare npx tabnas-lsp-gen would fetch an unrelated registry package.

What it provides

Diagnostics, semantic tokens, document symbols (outline) and completion, over incremental didChange sync, for any grammar the registry can reach. Grammars can be added without rebuilding the server: an installed plugin module, a serialized GrammarSpec, or a BNF dialect compiled at load time, declared per workspace folder and reloaded when the file changes.

Engine

Requires a @tabnas/parser providing the LSP engine contract — recovery, ruleDone and continuations — which ships from 0.9.0.

The peer range is deliberately open (>=0), the fleet convention, so an install resolves the newest published engine. That is what satisfies the contract in practice: install this package and npm gives you 0.9.0 or later. Pinning an older engine by hand is the one way to get a resolution that installs cleanly and then cannot serve — completion returns nothing.

Documentation

Full design, the dynamism ladder, the generator matrix and the security model are in doc/design.md. Contributor and agent guidance is in AGENTS.md.

License

MIT