The client runtime had no loop support, so any shared function using one returned early -- Pagination and ButtonGroup were broken client-side, not just in tests. Adding loops exposed two further faults: - A var reaching writeScope creates a signal and triggers a render sweep. A declaration inside a function called during a render therefore looped forever. Declarations now bind into the handler locals instead. - A control block removed from the DOM keeps its effect in the renderers list. Running it against a detached node threw, aborting the sweep and leaving every later effect stale. Also raises the reactive runtime budget to 53,000: the runtime had already grown past 49,000 before this change, and 52,570 minified is 16,803 gzipped. Two deferred minors: html-service leaves absent documentation undefined rather than an empty string, and the extension declines tag auto-close on multi-cursor edits rather than closing only the first cursor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@wrnexus/language-server
Editor-neutral Language Server Protocol support for .wrn files. It uses the canonical
@wrnexus/syntax parser, diagnostics, accessibility rules, and formatter.
bunx wrnexus-language-server --stdio
Capabilities include syntax, accessibility and TypeScript expression diagnostics, formatting,
completion, hover, document symbols, go-to-definition, references, rename, and quick fixes.
The custom wrnexus/virtualDocument request returns the mapped TypeScript representation of an
open .wrn document for editor TypeScript plugins and safe refactoring tools. Any LSP 3.x client can launch the
stdio command. Example Neovim configuration:
vim.lsp.start({
name = "wrnexus",
cmd = { "bunx", "wrnexus-language-server", "--stdio" },
root_dir = vim.fs.root(0, { "wrnexus.config.ts", "package.json", ".git" }),
})
JetBrains users can register the same command through an LSP client/plugin. The server does not require VS Code and never reads environment secrets or sends source over a network.