Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Support per-folder enable/disable for the singleton server in multi-root workspaces - #62

Draft
Eduardo Villalpando Mello (edvilme) with Copilot wants to merge 3 commits into
mainfrom
copilot/support-singleton-server-instance
Draft

Eduardo Villalpando Mello (edvilme) with Copilot wants to merge 3 commits into
mainfrom
copilot/support-singleton-server-instance

Conversation

Copilot AI commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Tool extensions consuming this library risk redundant LSP processes and duplicated diagnostics in multi-root workspaces. The TypeScript client already runs a singleton server (one client rooted at getProjectRoot(), per-folder settings forwarded via getExtensionSettings()), so the gap was the lack of a per-folder opt-out (e.g. pylint.enabled: false for a single folder).

Changes

  • settings.ts
    • isToolEnabledForWorkspace(namespace, workspace?, settingKey?) — reads the per-folder <namespace>.enabled boolean; defaults to enabled, settingKey overridable (e.g. 'enable').
    • getEnabledWorkspaceFolders(namespace, settingKey?) — folders for which the tool is enabled.
    • getExtensionSettings() now resolves settings only for enabled folders, so the shared server never lints opted-out folders. Backward compatible: unset → enabled.
  • index.ts — export the two new helpers.
  • Tests — cover default-enabled, explicit disable, custom setting key, and folder filtering through getExtensionSettings.
  • README — document the singleton model and per-folder enable API.

Example

// Disabled folders are omitted; the singleton server only receives enabled ones.
const settings = await getExtensionSettings('pylint', toolConfig, resolveInterpreter);

// Or query directly when registering per-folder providers:
const folders = getEnabledWorkspaceFolders('pylint');
const enabled = isToolEnabledForWorkspace('pylint', folder, 'enable');

Note: getExtensionSettings() filtering changes which folders reach the server when a tool exposes an enabled setting and a user disables a folder — worth a careful look during review, though defaults preserve existing behavior.

Copilot AI changed the title [WIP] Add support for singleton server instance in multi-root workspaces Support per-folder enable/disable for the singleton server in multi-root workspaces Jun 17, 2026
…eton-server-instance

# Conflicts:
#	typescript/src/settings.ts

Co-authored-by: edvilme <[email protected]>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Omitted folders still receive enabled server defaults, and a duplicate import prevents test compilation.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds per-folder tool enablement for singleton LSP servers in multi-root workspaces.

Changes:

  • Adds enablement helpers and workspace filtering.
  • Exports and documents the new APIs.
  • Adds multi-root tests.
File summaries
File Description
typescript/src/settings.ts Implements enablement filtering.
typescript/src/index.ts Exports new helpers.
typescript/tests/settingsWorkspace.test.ts Adds enablement tests.
README.md Documents multi-root behavior.
Review details
  • Files reviewed: 4/4 changed files
  • Comments generated: 3
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +346 to +347
workspaces.filter((w) => isToolEnabledForWorkspace(namespace, w)).map((w) =>
getWorkspaceSettings(namespace, w, toolConfig, resolveInterpreter),
Comment on lines +11 to 13
getExtensionSettings,
getExtraPaths,
getExtensionSettings,
Comment thread README.md
Comment on lines +75 to +77
- `getExtensionSettings(namespace, toolConfig, resolveInterpreter)` automatically
omits folders where the tool is disabled, so the shared server never lints
opted-out folders.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants