Adds a second reproducer covering the 'forever' branch of issue #22872:
when Pyright.spawn calls Npm.which('pyright') and the npm registry is
unreachable (sandboxed container), arborist.reify blocks indefinitely
with no timeout.
Changes:
- Adds optional Info.spawnEffect alongside the existing async Info.spawn.
spawnEffect returns an Effect that can yield from Npm.Service, making
npm lookups injectable for tests.
- Migrates Pyright to use spawnEffect, pulling the venv probing logic
into a reusable pyrightVenvInitialization helper. The legacy async
spawn stays for backwards compatibility.
- Threads Npm.Service through LSP.layer so getClients captures a stable
reference and uses it for any server that provides spawnEffect.
- Adds test/tool/write-lsp-spawn-hang.test.ts — mocks Npm.Service.which
with Effect.never and asserts the write tool still returns in < 10s.
Fails today (hangs forever); the fix must bound the touchFile tail
so the tool cannot wait on a wedged LSP spawn.
The two reproducers now cover both hang branches:
- write-lsp-hang.test.ts: 45s LSPClient.create initialize timeout
- write-lsp-spawn-hang.test.ts: unbounded Npm.which arborist.reify
Adds a failing regression test that reproduces the write tool hang
reported in #22872. The write tool calls lsp.touchFile + lsp.diagnostics
to enrich its output; if a matching LSP server spawns but never responds
to the initialize request, the tool blocks on LSPClient.create's 45s
withTimeout.
The test configures a fake LSP server (hanging-lsp-server.js) that
swallows every message and never replies, asserts the file is still
written correctly, and checks the tool returns within 10s. On dev today
the assertion fails with ~45s actual, proving the hang. The fix should
make this green by bounding the diagnostic-enrichment tail.
Extract error handling, parsing logic, and variable substitution into dedicated
modules. This reduces duplication between tui.json and opencode.json parsing
and makes the config system easier to extend for future config formats.
Adds explanatory comments to config.ts and plugin.ts clarifying:
- How plugin specs are stored and normalized during config loading
- Why plugin_origins tracks provenance for location-sensitive decisions
- Why path-like specs are resolved early to prevent reinterpretation during merges
- How plugin deduplication works while keeping origin metadata for writes and diagnostics
Fixes potential plugin resolution issues when switching between projects by wrapping
plugin loading in Instance.provide(). This ensures each plugin resolves dependencies
relative to its correct project directory instead of inheriting context from whatever
instance happened to be active.
Also reorganizes config loading code into focused modules (command.ts, managed.ts,
plugin.ts) to make the codebase easier to maintain and test.
Kit Langton