Create VS Code Python Tools LSP Package

[edvilme]

TL;DR
Due to the great amount of shared code among the VSCode Python Tools extensions, and no mechanism to ensure sync/parity, we need to extract all shared code into a PyPI and NPM package to be consumed by the extensions.

1. Background

Our team maintains several extensions that enable the use of Python formatting and linting tools directly from the editor, using LSP. These are:

• https://github.com/microsoft/vscode-isort
• https://github.com/microsoft/vscode-pylint
• https://github.com/microsoft/vscode-mypy
• https://github.com/microsoft/vscode-flake8
• https://github.com/microsoft/vscode-black-formatter

Due to their nature, these extensions are essentially wrappers for their respective tools, consisting mostly of workspace settings discovery mechanisms, Python interpreter/environment resolution, LSP handling, and tool spawning and communication. Hence, they share mostly the same codebase with few exceptions like output parsing, CLI arguments, feature availability, etc.

2. Motivation

The code for the extensions was originally bootstrapped from this template. However, with no mechanism to ensure syncing, the codebases from the different extensions tends to deviate over time. This causes duplicate issues with different fixes among the extensions, which makes maintaining the codebases simultaneously a very challenging task. An attempt was made to use agentic workflows detect deviations from the template, and while it aids in the chore, it does not guarantee a sustainable code base. Then, there is a need to have a single source of truth shared between the extension. So that a fix or implementation can be automatically consumed by all the codebases. The proposal is a mono-repo that exposes both PyPI and NPM packages.

3. Plan

This is an ambitious feat that requires having a deep understanding of both the template and the extensions' codebases, as well as major overhauls to all, in a way that exposes a reusable set of API's and maintains existing behavior with NO breaking changes. From the user's perspective, this should behave like an incremental update.

1. Feature parity: Identify solved bugs in different extensions

First, we need to ensure feature parity among the extensions. This includes making sure bugs previously fixed in one extension are not present in another one. This will help reduce the divergence (feature-wise) of the extensions and help keep track of edge cases. This can be achieved by comparing issues and pull requests between the extensions.

First, a list of all the issues across all repos should be obtained. Then, these should be grouped by their lowest common denominator. For each issue group, we should find the PR(s) in each repo that solved them. Issues that have not been solved or have no PRs in any of the repos should be discarded as out of scope. But issues that have been fixed in at least one of the repo's should be fixed in individual PRs for the rest of the repos

2. Test coverage

Tests on the extensions will be our way of avoiding introducing breaking changes. It is important that any special edge case or consideration is properly documented and covered by a test. All solved issues should have at least one associated test.

3. Identifying files / methods

Next, we would need to identify the files (and methods) that are shared across the extensions as they will be the focus of this migration. These should be classified as:

• Tool-Specific: Specific to the tool, not shared across the rest of the extensions
• Parametrizable: Shared across the rest of the extensions, but with different parameters
• Shared: Shared as-is across the extensions

4. Refactor files

In order to make the implementation easier, affected files should be refactored to be more interchangeable. This means having same implementations for methods, same methods in each file, etc. Whenever possible, parametrize behaviors and methods.

5. Mono-Repo

After that it will be easier to extract shared/parametrizable methods and code into its own codebase. The package will be structured in a monorepo called microsoft/vscode-python-tools-lsp and contain both a python and a typescript directory with the respective packages.

6. Implementation

During implementation and while testing, the mono-repo would be consumed via a git submodule. Code should be heavily refactored to use the package and ensure that all tests pass. Any failures should be documented so either the package or the implementation in the repo can be fixed.

7. Publishing

After the implementation and integration are done, the mono-repo should be configured with the correct pipelines and proper documentation to be published to both PyPI and NPM.

4. Next Steps

Afterwards, the new extensions should have 80% code reduction. The extensions should then consume the extension from the feed rather than as a git submodule. A new agentic workflow can be introduced for triaging issues and redirecting them to the mono-repo automatically.

[edvilme]

Per-Repo Fix Analysis

Purpose

This table identifies which bug fixes and feature gaps exist across the 5 VS Code Python tool extensions (black-formatter, flake8, isort, mypy, pylint) that share a common template codebase. The goal is to understand what needs to be fixed before and during the extraction of shared code into the vscode-python-tool-lsp package, and what will be automatically resolved by that extraction.

Methodology

1. Issue collection: Fetched all 710 issues (excluding dependency bumps, template syncs) across the 5 repos using the GitHub GraphQL API, including closedByPullRequestsReferences and timelineItems to discover linked PRs.
2. Same-repo deduplication: Merged issues within the same repo that share the same fixing PR (710 to 655 rows).
3. Cross-repo grouping: Used LLM-based analysis to identify issues that describe the same underlying problem across different repos, producing 35 cross-repo issue groups.
4. Per-repo expansion: Expanded each group into per-repo fix items, including gaps where an issue exists in some repos but hasn't been reported in others (87 total items).
5. Implementation verification: For each fix item, inspected the actual codebase (source files, settings, server code) and checked merged PRs via GitHub to determine if the fix is already implemented, partially implemented, or missing.
6. Priority classification: Classified each actionable item as infra (solvable in the shared package), tool-specific (per-extension only), or mixed.

How to read the table

• Is Implemented: yes = already fixed; partial = some aspects fixed, gaps remain; no = not implemented; irrelevant = doesn't apply to this tool type
• Priority: infra = will be solved by extracting shared code into vscode-python-tool-lsp (fix once, all repos benefit); tool-specific = must be handled per-extension; mixed = partly shared, partly tool-specific
• Related PRs: PRs from sibling repos that fixed the same issue — these serve as reference implementations for porting the fix

Impact

Of the 60 actionable items (37 not implemented + 23 partially implemented):

• 43 are infrastructure issues that the shared package extraction will solve — this is the strongest justification for the extraction
• 10 are tool-specific and will remain per-extension work
• The remaining 7 are mixed or need manual triage

---

Summary

Status	Count
yes	23
partial	23
no	37
irrelevant	4

Priority	Count	Meaning
infra	43	Solved by shared package extraction
tool-specific	10	Per-extension only
uncategorized	5	Needs manual triage
mixed	2	Partly infra, partly tool-specific

Full Table

Repo	Issue Description	Is Implemented	Priority	Fix Description	Repo Issue Tracking	Related Issues	Related PRs
microsoft/vscode-black-formatter	The Black formatter extension fails in multi-root workspaces, either requiring every workspace folder to have a valid Python interpreter or being unable to locate the interpreter at all, leaving some	yes	n/a	Implemented: Per-workspace settings via WORKSPACE_SETTINGS dict with _get_document_key()/_get_settings_by_document() resolving interpreter and settings per workspace folder. PR microsoft/vscode-black-formatter#10 added multi-root support, PR microsoft/vscode-black-formatter#237 fixed importStrategy	microsoft/vscode-black-formatter#370, microsoft/vscode-black-formatter#484
microsoft/vscode-black-formatter	The Black formatter extension does not discover configuration files (e.g., pyproject.toml) located outside the workspace root and fails to detect changes to configuration files at runtime, requiring a	partial	infra	Partially implemented: Config file watchers ARE implemented (configWatcher.ts watches pyproject.toml, .black, setup.cfg, tox.ini for changes/creates/deletes and triggers server restart via PR microsoft/vscode-black-formatter#631). However, hierarchical discovery beyond workspace root is NOT implemen	microsoft/vscode-black-formatter#627, microsoft/vscode-black-formatter#630, microsoft/vscode-black-formatter#236, microsoft/vscode-black-formatter#295, microsoft/vscode-black-formatter#364, microsoft/vscode-black-formatter#519		microsoft/vscode-isort#500, microsoft/vscode-isort#386, microsoft/vscode-isort#1992, microsoft/vscode-mypy#163, microsoft/vscode-mypy#422, microsoft/vscode-mypy#190, microsoft/vscode-mypy#316
microsoft/vscode-black-formatter	Python and Black processes spawned by the extension are not properly terminated when VS Code is closed, leaving orphan processes running that continue to consume system resources.	yes	n/a	Implemented: deactivate() in extension.ts stops the language client. lsp_jsonrpc.py has ProcessManager.stop_all_processes() registered with atexit. LSP server has shutdown/exit handlers that call jsonrpc.shutdown_json_rpc(). PR microsoft/vscode-black-formatter#637 also fixed duplicate server handlin			microsoft/vscode-isort#224
microsoft/vscode-black-formatter	When the Black formatter is running on a file, there is no visual indication of progress, so users cannot tell whether formatting is in progress or if the extension has stalled.	no	infra	Required fix: Add a progress or busy indicator (e.g., a status bar spinner) that is shown while Black is actively formatting a file. PR microsoft/vscode-pylint#687 can be used as a reference implementation.	microsoft/vscode-black-formatter#56		microsoft/vscode-pylint#687
microsoft/vscode-black-formatter	The Black formatter extension silently fails when Black is misconfigured, missing, or running an unsupported version, giving the user no error message or indication that formatting did not occur.	yes	n/a	Implemented: showNotifications setting implemented with 4 levels (off/onError/onWarning/always) in package.json. Python LSP server has log_error(), log_warning(), log_always() functions that call window_show_message based on LS_SHOW_NOTIFICATION env var. Error paths log failures with actionable mess			microsoft/vscode-pylint#103
microsoft/vscode-black-formatter	The Black formatter extension does not support formatting Jupyter Notebook (.ipynb) files or individual notebook cells within VS Code.	yes	n/a	Implemented: Document selector includes vscode-notebook and vscode-notebook-cell schemes (utilities.ts). LSP server handles notebook-cell URIs in _get_document_path(), converts .ipynb cells to .py in _get_filename_for_black(), passes --ipynb for .ipynb files in _get_args_by_file_extension(), and han	microsoft/vscode-black-formatter#87		microsoft/vscode-mypy#473, microsoft/vscode-pylint#742
microsoft/vscode-black-formatter	The Black formatter extension does not offer quick-fix code actions to suppress or ignore specific formatting issues via inline comments (e.g., # fmt: off/on).	no	tool-specific	Required fix: This issue hasn't been reported yet in vscode-black-formatter but exists in other repos. Implement code action providers that offer quick fixes to insert Black suppression comments (# fmt: off / # fmt: on) for specific code regions.
microsoft/vscode-black-formatter	The Black formatter extension can only format the currently open file and does not support formatting all files across the entire project or workspace at once.	no	uncategorized	Required fix: This issue hasn't been reported yet in vscode-black-formatter but exists in other repos. Add a workspace-wide formatting command that runs Black across all Python files in the project, reporting results in aggregate. PR microsoft/vscode-mypy#108 can be used as a reference implementatio			microsoft/vscode-mypy#108
microsoft/vscode-black-formatter	The Black formatter extension does not respect the python.envFile setting or .env files, so environment variables needed for Black's operation (e.g., custom paths or configuration) are not loaded.	no	infra	Required fix: This issue hasn't been reported yet in vscode-black-formatter but exists in other repos. Update the extension to read and apply environment variables from the file specified by python.envFile (or .env by default) when spawning the Black process.
microsoft/vscode-black-formatter	The Black formatter extension does not support an extraPaths setting (analogous to python.analysis.extraPaths), preventing Black from resolving imports from additional source directories outside the d	no	infra	Required fix: Add an extraPaths configuration option that appends additional directories to the Python path when invoking Black, so it can correctly process files with non-standard import structures. PR microsoft/vscode-pylint#524 can be used as a reference implementation.	microsoft/vscode-black-formatter#553		microsoft/vscode-pylint#524
microsoft/vscode-black-formatter	The importStrategy setting causes conflicts between the bundled Black version and the one installed in the user's environment; the fromEnvironment fallback to the bundled version is broken, and the be	yes	n/a	Implemented: importStrategy setting with fromEnvironment/useBundled enum fully implemented. update_sys_path() handles priority correctly: useBundled inserts at front of sys.path, fromEnvironment appends (so environment version takes priority with bundled as fallback). Setting propagated via LS_IMPOR	microsoft/vscode-black-formatter#369, microsoft/vscode-black-formatter#208, microsoft/vscode-black-formatter#233		microsoft/vscode-pylint#244
microsoft/vscode-black-formatter	The Black formatter extension does not provide a cwd (current working directory) setting, so users cannot control the working directory from which Black is invoked, which affects config file resolutio	yes	n/a	Implemented: cwd setting fully implemented in package.json and lsp_server.py get_cwd() with 9 variable substitutions (workspaceFolder, fileDirname, file, fileBasename, etc.). Used when spawning Black process. PR microsoft/vscode-black-formatter#639 enhanced variable substitution, PR microsoft/vscode			microsoft/vscode-isort#260, microsoft/vscode-isort#404, microsoft/vscode-isort#444, microsoft/vscode-isort#543, microsoft/vscode-isort#639, microsoft/vscode-isort#712, microsoft/vscode-pylint#251
microsoft/vscode-black-formatter	When Black reports formatting diagnostics, the highlighted range in the editor covers entire functions or class bodies instead of pinpointing the specific line or region that needs formatting.	irrelevant	n/a	tool-specific. Black formatter is a formatter only and does not publish diagnostics. No diagnostic range highlighting exists to improve.
microsoft/vscode-black-formatter	The Black formatter extension significantly slows down file save operations, with format-on-save taking several seconds to complete and blocking the editor.	partial	infra	Partially implemented: Persistent LSP server architecture avoids process startup overhead. When same interpreter, Black runs in-process as a module (utils.run_module). When different interpreter, uses cached JSON-RPC connections. However, no explicit timeout mechanism exists to prevent indefinite bl			microsoft/vscode-pylint#457
microsoft/vscode-black-formatter	The Black formatter extension only runs on file save and does not support formatting or reporting formatting issues as the user types, unlike the deprecated python.linting.lintOnChange behavior.	no	mixed	Required fix: This issue hasn't been reported yet in vscode-black-formatter but exists in other repos. Add a formatting-on-change mode that runs Black in check mode as the user types, providing real-time feedback on formatting issues. PRs microsoft/vscode-flake8#294 and microsoft/vscode-pylint#368 c			microsoft/vscode-flake8#294, microsoft/vscode-pylint#368
microsoft/vscode-black-formatter	Diagnostic messages from the Black formatter do not include clickable links to documentation explaining the specific error or formatting rule being enforced.	irrelevant	n/a	tool-specific. Black formatter does not publish diagnostics, so diagnostic documentation links (codeDescription.href) are not applicable.			microsoft/vscode-mypy#58
microsoft/vscode-black-formatter	The Black formatter extension does not report files that need formatting as diagnostics in the VS Code Problems panel, so users have no way to see which files are unformatted without manually opening	no	tool-specific	Required fix: Add a check mode that runs Black with --check across workspace files and surfaces files needing formatting as warning diagnostics in the Problems panel, allowing users to see and navigate to all unformatted files.	microsoft/vscode-black-formatter#164
microsoft/vscode-flake8	The Flake8 extension's bundled libraries (pygls, typing_extensions, etc.) cause crashes or import errors on certain Python versions due to version incompatibilities, particularly around the pygls v1-t	yes	n/a	Implemented: pygls v2.0.1 and typing_extensions 4.15.0 are already bundled. Merged PR microsoft/vscode-flake8#367 ('Update to Pygls 2') completed the v1-to-v2 migration.			microsoft/vscode-black-formatter#141, microsoft/vscode-black-formatter#608, microsoft/vscode-isort#130, microsoft/vscode-pylint#641
microsoft/vscode-flake8	Users cannot install the stable/release version of the Flake8 extension from the VS Code Marketplace—only pre-release versions appear, or they get 'no release version' errors.	partial	uncategorized	Partially implemented: Both release ('vsce-package') and pre-release ('vsce-package-pre') packaging scripts exist, but the current manifest has 'preview: true' and version '2026.3.0-dev'. No automated publishing workflow was found. Release infrastructure exists but stable publishing may not be activ
microsoft/vscode-flake8	The Flake8 extension fails to discover configuration files (setup.cfg, .flake8, tox.ini) located outside the workspace root and does not automatically detect changes to configuration files without a m	yes	n/a	Implemented: Recursive upward config discovery is implemented in lsp_server.py (_get_document_key walks parent directories). File watchers in configWatcher.ts monitor .flake8, setup.cfg, and tox.ini for changes/creation/deletion and auto-restart the server.			microsoft/vscode-black-formatter#631, microsoft/vscode-black-formatter#366, microsoft/vscode-isort#500, microsoft/vscode-isort#386, microsoft/vscode-isort#1992, microsoft/vscode-mypy#163, microsoft/vscode-mypy#422, microsoft/vscode-mypy#190, microsoft/vscode-mypy#316
microsoft/vscode-flake8	Python/Flake8 processes spawned by the extension are not properly terminated when VS Code is closed, leaving orphan processes that consume system resources indefinitely.	yes	n/a	Implemented: Process cleanup is implemented: deactivate() in extension.ts calls lsClient.stop(), all disposables are tracked and disposed, and lsp_jsonrpc.py registers atexit cleanup handlers.			microsoft/vscode-isort#224
microsoft/vscode-flake8	Users have no visual indication when Flake8 is actively linting a file, making it unclear whether the extension is working or has stalled.	no	infra	Required fix: This issue hasn't been reported in vscode-flake8 yet but exists in other extensions. Add a progress indicator (e.g., status bar spinner or VS Code progress notification) while Flake8 is running. Reference PR: microsoft/vscode-pylint#687.			microsoft/vscode-pylint#687
microsoft/vscode-flake8	The Flake8 extension silently fails when Flake8 is misconfigured, missing required plugins, or running an unsupported version, with no error message or indication of failure shown to the user.	partial	infra	Partially implemented: Stderr output from flake8 is always logged to the Output channel. User-visible notifications are available via the flake8.showNotifications setting (supports 'onError', 'onWarning', 'always'), but this defaults to 'off', so failures are silent unless the user configures it. Re	microsoft/vscode-flake8#242		microsoft/vscode-pylint#103
microsoft/vscode-flake8	The Flake8 extension does not support linting Jupyter Notebook (.ipynb) files or individual notebook cells within VS Code.	yes	n/a	Implemented: Full Jupyter Notebook support implemented via merged PR microsoft/vscode-flake8#437 ('Add Jupyter notebook cell support via LSP 3.17 Notebook Document Sync'). Handles notebook open/change/save/close events with per-cell linting and vscode-notebook-cell:// URI support.			microsoft/vscode-black-formatter#664, microsoft/vscode-mypy#473, microsoft/vscode-pylint#742
microsoft/vscode-flake8	The Flake8 extension only lints the currently open file; there is no way to lint the entire project or workspace at once to get a full overview of all issues.	no	tool-specific	Required fix: Add a command or setting to run Flake8 across all Python files in the workspace and populate the Problems panel with the results. Reference PR: microsoft/vscode-mypy#108.	microsoft/vscode-flake8#244		microsoft/vscode-mypy#108
microsoft/vscode-flake8	Running Flake8 via the VS Code extension produces different linting results than running Flake8 directly from the command line, causing confusion about which configuration or Python environment is bei	partial	infra	Partially implemented: The exact flake8 command, CWD, and execution mode are logged to the Output channel for debugging. CWD is configurable via flake8.cwd with variable substitution. However, there is no explicit guarantee of identical environment variable propagation, and no envFile/.env support e
microsoft/vscode-flake8	The Flake8 extension does not respect the python.envFile setting or .env files, so environment variables needed for import resolution or plugin configuration are not available to the Flake8 process.	no	infra	Required fix: This issue hasn't been reported in vscode-flake8 yet but exists in other extensions. Read and apply environment variables from the configured python.envFile (or workspace .env) when spawning the Flake8 server process.
microsoft/vscode-flake8	The Flake8 extension does not support an extraPaths setting (like python.analysis.extraPaths), so Flake8 cannot resolve imports from additional source directories outside the default Python path.	no	infra	Required fix: This issue hasn't been reported in vscode-flake8 yet but exists in other extensions. Add a flake8.extraPaths setting that appends additional directories to PYTHONPATH when running Flake8. Reference PR: microsoft/vscode-pylint#524.			microsoft/vscode-pylint#524
microsoft/vscode-flake8	The Flake8 extension fails to process files or projects that involve symbolic links, raising ValueError exceptions or silently skipping symlinked files and directories.	yes	n/a	Implemented: Symlink handling implemented via merged PR microsoft/vscode-flake8#362 ('Symlinks should not be resolved when getting...'). The normalize_path() utility selectively resolves symlinks: workspace paths preserve symlinks for correct mapping, while file-type checks (site-packages, stdlib) r			microsoft/vscode-black-formatter#460, microsoft/vscode-black-formatter#4215, microsoft/vscode-mypy#396
microsoft/vscode-flake8	The Flake8 extension's importStrategy setting causes conflicts between bundled and environment-installed packages; the 'fromEnvironment' fallback to the bundled version is broken, and the behavior is	yes	n/a	Implemented: importStrategy properly implemented with 'useBundled' (inserts bundled libs at start of sys.path) and 'fromEnvironment' (appends bundled libs at end, giving environment packages priority). Fallback works correctly: when fromEnvironment is set, bundled packages serve as fallback if envir			microsoft/vscode-black-formatter#237, microsoft/vscode-pylint#244
microsoft/vscode-flake8	The Flake8 extension has no cwd (current working directory) setting, so users cannot control the working directory used when running Flake8—a capability that existed in the deprecated python.linting.c	yes	n/a	Implemented: flake8.cwd setting fully implemented with variable substitution (${workspaceFolder}, ${fileDirname}, ${file}, etc.), thread-safe CWD changes, and graceful fallback. PR microsoft/vscode-flake8#431 fixed spawn failures with unresolvable cwd values.			microsoft/vscode-isort#260, microsoft/vscode-isort#404, microsoft/vscode-isort#444, microsoft/vscode-isort#543, microsoft/vscode-isort#639, microsoft/vscode-isort#712, microsoft/vscode-pylint#251
microsoft/vscode-flake8	Flake8 diagnostics highlight entire functions or class bodies instead of just the specific line with the issue, making it difficult to identify the actual problem location in the editor.	yes	n/a	Implemented: Diagnostics already use precise single-character positions parsed from flake8's line/column output (start == end at exact error position). The described issue of highlighting entire functions/class bodies does not exist in this codebase.
microsoft/vscode-flake8	The Flake8 extension produces errors or warnings visible in the VS Code Developer Tools console, indicating bugs in the extension's client-side TypeScript/JavaScript code.	partial	infra	Partially implemented: Error handling exists in critical paths: try-catch on server stop/start, disposable cleanup, structured logging via OutputChannelLogger. PRs microsoft/vscode-flake8#401 and microsoft/vscode-flake8#428 improved error handling. However, no comprehensive DevTools error audit has
microsoft/vscode-flake8	The Flake8 extension significantly slows down file save operations, with on-save linting taking many seconds to complete and blocking the editor.	partial	infra	Partially implemented: Linting runs asynchronously via the LSP architecture (pygls), so save operations are not blocked in the editor. Server restarts are debounced at 2000ms. However, there is no debouncing of rapid individual file saves at the linting level. Required fix: This issue hasn't been re			microsoft/vscode-pylint#457
microsoft/vscode-flake8	Flake8 diagnostic messages in the Problems panel do not include clickable links to documentation explaining the specific error code or rule that was violated.	no	tool-specific	Required fix: This issue hasn't been reported in vscode-flake8 yet but exists in other extensions. Set the diagnostics' codeDescription.href field to link each Flake8 error code (e.g., E501, W503) to its documentation page. Reference PR: microsoft/vscode-mypy#58.			microsoft/vscode-mypy#58
microsoft/vscode-flake8	There is no way to run Flake8 in a check/diff mode that reports files needing attention as diagnostics in the VS Code Problems panel without modifying the files.	irrelevant	n/a	tool-specific - Flake8 is a linter that never modifies files, so 'check mode' (as applicable to formatters) is inherently its default behavior. The --diff flag (lint only changed lines) is not supported, but the core concern about non-destructive diagnostics does not apply since flake8 already only
microsoft/vscode-isort	The word "Python" is inconsistently capitalized (e.g., lowercase "python") in user-facing strings such as settings descriptions, error messages, and UI labels in the vscode-isort extension.	partial	infra	Partially implemented: Settings descriptions in package.nls.json consistently use capital "Python", and the main user-facing l10n string is correct. However, developer-visible log/error messages in extension.ts, runner.ts, and python.ts still use lowercase "python" (e.g., "Select python interpreter"			microsoft/vscode-black-formatter#325, microsoft/vscode-flake8#365, microsoft/vscode-pylint#390
microsoft/vscode-isort	The vscode-isort extension has no ignorePatterns setting, so users cannot exclude specific files or folders (e.g., generated code, vendored dependencies) from isort processing.	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but is widely reported across other extensions. Add an ignorePatterns setting that accepts glob patterns and skip matching files before invoking isort. PRs microsoft/vscode-black-formatter#192, microsoft/vscode-flake8#239, microsoft			microsoft/vscode-black-formatter#192, microsoft/vscode-flake8#239, microsoft/vscode-flake8#327, microsoft/vscode-mypy#220, microsoft/vscode-mypy#399, microsoft/vscode-pylint#415, microsoft/vscode-pylint#449, microsoft/vscode-pylint#452
microsoft/vscode-isort	VS Code variable references like ${workspaceFolder} and environment variables in isort settings (e.g., isort.args, isort.path) are not expanded, causing paths and arguments to be passed as liter	yes	n/a	Implemented: settings.ts has a resolveVariables() function that expands ${workspaceFolder}, ${userHome}, ${cwd}, ${workspaceFolder:name}, ${env:KEY}, and ${interpreter} for isort.args, isort.path, isort.cwd, and isort.interpreter settings. Additionally, PR microsoft/vscode-isort#543 added cwd variab			microsoft/vscode-black-formatter#216, microsoft/vscode-flake8#102
microsoft/vscode-isort	When isort is sorting imports on a file, there is no visual progress or busy indicator in VS Code, leaving users unsure whether the extension is working or has stalled.	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but exists in other extensions. Add a VS Code progress notification (e.g., using window.withProgress) while isort is actively processing a file. PR microsoft/vscode-pylint#687 can be used as a reference implementation.			microsoft/vscode-pylint#687
microsoft/vscode-isort	The vscode-isort extension does not offer quick-fix code actions to suppress isort warnings by adding inline comments (e.g., # isort: skip or # isort: skip_file), forcing users to manually add sup	no	tool-specific	Required fix: This issue hasn't been reported yet in vscode-isort but exists in other linting extensions. Implement code action providers that offer quick fixes to insert isort suppression comments at the relevant line or file level. No reference PRs are available from other repos.
microsoft/vscode-isort	The vscode-isort extension only sorts imports in the currently open file; there is no way to run isort across the entire project or workspace at once.	no	uncategorized	Required fix: This issue hasn't been reported yet in vscode-isort but is requested in other extensions. Add a command (e.g., "isort: Sort Imports in Workspace") that runs isort across all Python files in the workspace. PR microsoft/vscode-mypy#108 can be used as a reference implementation.			microsoft/vscode-mypy#108
microsoft/vscode-isort	The vscode-isort extension does not respect the python.envFile setting or .env files, so environment variables that affect import resolution (e.g., PYTHONPATH) are not loaded when isort runs.	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but exists in other extensions. Read and apply environment variables from the configured python.envFile (or .env by default) before spawning the isort process. No reference PRs are available from other repos.
microsoft/vscode-isort	The vscode-isort extension does not support an extraPaths setting, so isort cannot resolve imports from additional source directories outside the workspace root (e.g., monorepo subdirectories or sha	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but exists in other extensions. Add an isort.extraPaths setting that appends additional directories to the Python path when running isort. PR microsoft/vscode-pylint#524 can be used as a reference implementation.			microsoft/vscode-pylint#524
microsoft/vscode-isort	The vscode-isort extension fails to process files or projects that use symbolic links, raising errors (e.g., ValueError) or silently skipping symlinked files and directories.	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but exists in other extensions. Resolve symbolic links before passing file paths to isort, and ensure workspace path resolution handles symlinked directories correctly. PRs microsoft/vscode-black-formatter#460, microsoft/vscode-black-			microsoft/vscode-black-formatter#460, microsoft/vscode-black-formatter#4215, microsoft/vscode-mypy#396
microsoft/vscode-isort	Arguments specified in the isort.args setting are silently ignored or not properly passed to the underlying isort tool, so custom flags like --profile, --line-length, or --settings-path have n	yes	n/a	Implemented: isort.args is properly read in settings.ts getArgs(), passed through resolveVariables(), and appended to the isort command line in both runner.ts (getExecutablePathWithArgs: ...settings.args) and lsp_server.py (_run_tool_on_document: settings["args"] is included in argv). Args are corre			microsoft/vscode-flake8#361, microsoft/vscode-flake8#362
microsoft/vscode-isort	When isort reports a diagnostic (e.g., unsorted imports), the highlight range covers entire functions or large code blocks instead of just the specific import lines, making it hard to identify the act	irrelevant	n/a	tool-specific - isort only outputs a single "imports are incorrectly sorted" error without line-specific details. The extension already narrows the diagnostic range to just the first import line (import_line to import_line+1) in both lsp_server.py _parse_output() and runner.ts diagnosticRunner(). Th
microsoft/vscode-isort	The vscode-isort extension makes file save operations very slow, with isort's on-save import sorting taking several seconds and blocking the save workflow.	no	infra	Required fix: Investigate and optimize the on-save isort execution to reduce latency. Consider running isort asynchronously, caching results for unchanged files, or adding a timeout. PR microsoft/vscode-pylint#457 can be used as a reference implementation.	microsoft/vscode-isort#160, microsoft/vscode-isort#175		microsoft/vscode-pylint#457
microsoft/vscode-isort	The vscode-isort extension only checks import order on file save; there is no option to sort or flag unsorted imports as the user types, unlike the deprecated python.linting.lintOnChange behavior.	no	infra	Required fix: This issue hasn't been reported yet in vscode-isort but is requested in other extensions. Add an isort.check.onChange setting that triggers isort checking on document change events with appropriate debouncing. PRs microsoft/vscode-flake8#294 and microsoft/vscode-pylint#368 can be use			microsoft/vscode-flake8#294, microsoft/vscode-pylint#368
microsoft/vscode-isort	Diagnostic messages from isort do not include clickable links to documentation explaining the specific error or rule, forcing users to manually search for what an isort warning means.	no	tool-specific	Required fix: This issue hasn't been reported yet in vscode-isort but is requested in other extensions. Add a codeDescription.href property to diagnostics that links to the relevant isort documentation page for each error code. PR microsoft/vscode-mypy#58 can be used as a reference implementation.			microsoft/vscode-mypy#58
microsoft/vscode-mypy	Extension settings in package.json are not ordered alphabetically, making them hard to find and inconsistent with other Python tool extensions.	no	infra	Required fix: Re-order all mypy extension settings in package.json alphabetically. This issue has not been reported yet in vscode-mypy but exists in other tool extensions. Reference PRs: microsoft/vscode-black-formatter#235, microsoft/vscode-isort#156.			microsoft/vscode-black-formatter#235, microsoft/vscode-isort#156
microsoft/vscode-mypy	The bundled Python library dependencies (pygls, lsprotocol, cattrs, etc.) shipped with the extension are outdated and may lack bug fixes or compatibility improvements.	yes	n/a	Implemented: Bundled dependencies are recently updated: pygls 2.0.1, lsprotocol 2025.0.0, cattrs 24.1.2, typing-extensions 4.12.2, attrs 25.1.0, mypy 1.15.0, packaging 24.2, tomli 2.2.1.			microsoft/vscode-black-formatter#326, microsoft/vscode-flake8#267, microsoft/vscode-isort#332, microsoft/vscode-pylint#704
microsoft/vscode-mypy	The ignorePatterns setting does not work correctly—users cannot reliably exclude files or folders from mypy analysis, and glob pattern matching is broken or incomplete.	partial	infra	Partially implemented: ignorePatterns setting exists and uses fnmatch-based glob matching in lsp_utils.py (both relative path and filename matching). PR microsoft/vscode-mypy#325 improved global settings defaults. However, original issues remain open suggesting edge cases with certain glob patterns.	microsoft/vscode-mypy#213, microsoft/vscode-mypy#338, microsoft/vscode-mypy#362		microsoft/vscode-black-formatter#192, microsoft/vscode-flake8#239, microsoft/vscode-flake8#327, microsoft/vscode-pylint#415, microsoft/vscode-pylint#449, microsoft/vscode-pylint#452
microsoft/vscode-mypy	The extension crashes or fails to start due to version incompatibilities between bundled libraries (pygls, typing_extensions) and specific Python versions, particularly when migrating to pygls v2.	yes	n/a	Implemented: pygls v2 migration completed via PRs microsoft/vscode-mypy#400 and microsoft/vscode-mypy#401. Bundled pygls is now 2.0.1 with compatible lsprotocol 2025.0.0, cattrs 24.1.2, and typing-extensions 4.12.2.	microsoft/vscode-mypy#431		microsoft/vscode-black-formatter#141, microsoft/vscode-black-formatter#608, microsoft/vscode-isort#130, microsoft/vscode-pylint#641
microsoft/vscode-mypy	The mypy extension fails to work in multi-root VS Code workspaces, either requiring all workspace folders to have a valid Python interpreter or failing to find the interpreter entirely.	yes	n/a	Implemented: Multi-root workspace support exists. getExtensionSettings() iterates all workspace folders calling getWorkspaceSettings() per folder. getProjectRoot() in utilities.ts selects the appropriate workspace by longest path match.
microsoft/vscode-mypy	The extension's LSP client fails to establish or maintain a connection to the mypy server, showing errors like "couldn't create connection" or "connection is erroring" in the output.	partial	infra	Partially implemented: Has retry mechanism (restartServer with 1000ms delay), server state monitoring (onDidChangeState), and manual restart command. But no automatic reconnection on LSP connection errors — relies on manual restart or retry timer. Required fix: Fix the LSP server connection lifecycl			microsoft/vscode-black-formatter#449, microsoft/vscode-black-formatter#410
microsoft/vscode-mypy	Mypy does not discover configuration files (mypy.ini, setup.cfg, pyproject.toml) located outside the workspace root, and does not automatically reload when configuration files are changed.	partial	mixed	Partially implemented: Config file watchers implemented (PR microsoft/vscode-mypy#422, configWatcher.ts watches mypy.ini, .mypy.ini, pyproject.toml, setup.cfg and restarts server on changes). ${nearestConfig} CWD variable walks up directories to find config files (PR microsoft/vscode-mypy#357). Howe	microsoft/vscode-mypy#122, microsoft/vscode-mypy#190, microsoft/vscode-mypy#259		microsoft/vscode-black-formatter#631, microsoft/vscode-black-formatter#366, microsoft/vscode-isort#500, microsoft/vscode-isort#386, microsoft/vscode-isort#1992
microsoft/vscode-mypy	When VS Code is closed, the mypy Python processes spawned by the extension are not terminated, leaving orphan processes that consume system resources indefinitely.	partial	infra	Partially implemented: LSP server on_exit() calls dmypy kill and on_shutdown() calls dmypy stop for daemon cleanup. Extension deactivate() stops LSP client. But this only handles daemon mode (preferDaemon), and may not catch all spawned processes if VS Code exits abruptly without triggering deactiva	microsoft/vscode-mypy#236, microsoft/vscode-mypy#291		microsoft/vscode-isort#224
microsoft/vscode-mypy	There is no visual indication when mypy is actively analyzing a file, leaving users unsure whether analysis is in progress or has completed.	no	infra	Required fix: Add a progress indicator (e.g., status bar spinner or progress notification) that shows when mypy is actively running analysis. Reference PR: microsoft/vscode-pylint#687.	microsoft/vscode-mypy#193		microsoft/vscode-pylint#687
microsoft/vscode-mypy	When mypy is misconfigured, missing required plugins, or running an unsupported version, the extension silently fails with no error messages or indication of the problem to the user.	partial	infra	Partially implemented: Server logs errors via LSP_SERVER.window_log_message(MessageType.Error) with full tracebacks on exceptions. Version check warns if mypy < 1.0.0. showNotifications setting controls notification level. However, specific plugin-missing or misconfiguration cases are not detected —			microsoft/vscode-pylint#103
microsoft/vscode-mypy	The mypy extension does not support analyzing Jupyter Notebook (.ipynb) files or notebook cells within VS Code.	no	tool-specific	Required fix: Add support for running mypy on Jupyter Notebook files and individual notebook cells. Reference PRs: microsoft/vscode-black-formatter#664, microsoft/vscode-pylint#742.	microsoft/vscode-mypy#86		microsoft/vscode-black-formatter#664, microsoft/vscode-pylint#742
microsoft/vscode-mypy	There are no quick fix code actions to suppress mypy diagnostics by inserting inline "# type: ignore" comments on the affected line.	no	tool-specific	Required fix: Implement code actions that offer to add "# type: ignore[error-code]" comments to suppress specific mypy diagnostics directly from the editor's quick fix menu.	microsoft/vscode-mypy#56
microsoft/vscode-mypy	Mypy only checks the currently open file rather than the entire project or workspace, so users miss errors in files they have not opened.	yes	n/a	Implemented: reportingScope setting exists with 'file' (default), 'workspace', and 'custom' options. When set to 'workspace', diagnostics from all files mypy discovers are reported in the Problems panel, not just the open file. PR microsoft/vscode-mypy#352 also improved custom scope to report only f	microsoft/vscode-mypy#81, microsoft/vscode-mypy#164, microsoft/vscode-mypy#234
microsoft/vscode-mypy	The mypy extension does not respect the python.envFile setting or .env files, so environment variables needed for import resolution or configuration are not available to mypy.	no	infra	Required fix: Read and apply environment variables from the python.envFile setting and .env files before launching the mypy process, so MYPYPATH and other env-based configuration works correctly.	microsoft/vscode-mypy#154
microsoft/vscode-mypy	There is no extraPaths setting to tell mypy about additional source directories, causing unresolved import errors for projects with non-standard directory structures.	partial	infra	Partially implemented: The Python LSP server reads extraPaths from settings and sets MYPYPATH accordingly. The TS extension reads python.analysis.extraPaths as a fallback (settings.ts). However, there is no dedicated mypy-type-checker.extraPaths setting in package.json — it only works via the legacy			microsoft/vscode-pylint#524
microsoft/vscode-mypy	The importStrategy setting causes conflicts between the bundled and environment-installed mypy packages—the "fromEnvironment" fallback to the bundled version is broken, and the behavior is poorly docu	partial	infra	Partially implemented: importStrategy logic exists: 'useBundled' inserts bundled path first in sys.path; 'fromEnvironment' appends bundled path (so environment takes priority, bundled is fallback). Basic fallback mechanism works, but multiple open issues suggest edge cases where fromEnvironment beha	microsoft/vscode-mypy#172, microsoft/vscode-mypy#217, microsoft/vscode-mypy#184, microsoft/vscode-mypy#331		microsoft/vscode-black-formatter#237, microsoft/vscode-pylint#244
microsoft/vscode-mypy	There is no cwd (current working directory) setting to control the working directory from which mypy runs, which was previously available via the deprecated python.linting.cwd setting.	yes	n/a	Implemented: mypy-type-checker.cwd setting exists in package.json with default ${workspaceFolder}. Supports variable substitution including ${fileDirname}, ${nearestConfig}, ${workspaceFolder}, and many others. get_cwd() in lsp_server.py implements full variable resolution. PR microsoft/vscode-mypy#			microsoft/vscode-isort#260, microsoft/vscode-isort#404, microsoft/vscode-isort#444, microsoft/vscode-isort#543, microsoft/vscode-isort#639, microsoft/vscode-isort#712, microsoft/vscode-pylint#251
microsoft/vscode-mypy	Mypy diagnostics highlight entire functions or class bodies instead of just the specific line with the error, making it difficult to identify the actual problem location.	partial	tool-specific	Partially implemented: The server parses line:character positions from mypy output and passes --show-error-end (for mypy >= 0.991) to get precise end positions. With --show-error-end, highlights are character-precise. Without it, ranges collapse to a single character. However, open issues suggest th	microsoft/vscode-mypy#262, microsoft/vscode-mypy#429
microsoft/vscode-mypy	The extension does not provide equivalents for deprecated Python extension settings (python.linting.mypyEnabled, python.linting.mypyArgs, etc.) and has no migration path from the legacy configuration.	partial	infra	Partially implemented: logLegacySettings() detects and logs deprecation warnings for python.linting.mypyEnabled, python.linting.cwd, python.linting.mypyArgs, and python.linting.mypyPath. However, there is NO automatic migration — settings are not copied over, users must manually update. No disable s			microsoft/vscode-black-formatter#339, microsoft/vscode-isort#226
microsoft/vscode-mypy	The mypy extension produces errors or warnings visible in the VS Code Developer Tools console, indicating bugs in the extension's client-side TypeScript code.	no	infra	Required fix: Debug and fix the client-side errors appearing in the VS Code Developer Tools console to ensure clean extension operation. This issue has not been reported yet in vscode-mypy but exists in other tool extensions.
microsoft/vscode-mypy	The mypy extension significantly slows down file save operations, with analysis running synchronously and blocking the save for several seconds.	no	infra	Required fix: Optimize the on-save analysis to run asynchronously and avoid blocking the file save operation, or add debouncing to prevent redundant mypy invocations. This issue has not been reported yet in vscode-mypy but exists in other tool extensions. Reference PR: microsoft/vscode-pylint#457.			microsoft/vscode-pylint#457
microsoft/vscode-mypy	Mypy diagnostics are only updated when a file is saved; there is no option to run analysis as the user types, providing real-time feedback.	no	uncategorized	Required fix: Add a lintOnChange or equivalent setting that triggers mypy analysis on document changes (with debouncing) rather than only on file save. This issue has not been reported yet in vscode-mypy but exists in other tool extensions. Reference PRs: microsoft/vscode-flake8#294, microsoft/vscod			microsoft/vscode-flake8#294, microsoft/vscode-pylint#368
microsoft/vscode-mypy	There is no way to run mypy in a check-only mode that reports files needing attention as diagnostics in the VS Code Problems panel, useful for project-wide type-checking workflows.	yes	n/a	Implemented: reportingScope setting provides this capability. Setting it to 'workspace' runs mypy and reports all diagnostics across the workspace in the Problems panel. The 'custom' option lets mypy configuration define scope. This effectively provides project-wide type-checking visibility.
microsoft/vscode-pylint	The Pylint extension ships outdated bundled Python library dependencies (pygls, lsprotocol, etc.), causing compatibility issues, missing bug fixes, and potential crashes with newer Python versions.	yes	n/a	Implemented: requirements.txt shows pygls==2.0.1 and lsprotocol==2025.0.0 (current latest versions). Dependencies are up to date.	microsoft/vscode-pylint#396, microsoft/vscode-pylint#618		microsoft/vscode-black-formatter#326, microsoft/vscode-flake8#267, microsoft/vscode-isort#332
microsoft/vscode-pylint	The Pylint extension incorrectly identifies user source files as standard library files and skips linting them, or shows intrusive "Skipping standard library file" notifications for files that should	no	infra	Required fix: Fix the standard library file detection logic to correctly distinguish user source files from standard library files. This issue hasn't been reported yet in vscode-pylint but exists in other repos; reference PR microsoft/vscode-flake8#385 for the fix implementation.			microsoft/vscode-flake8#385
microsoft/vscode-pylint	The Pylint extension fails to find, resolve, or use the correct Python interpreter, resulting in server launch failures, ENOENT errors, or incorrect interpreter selection—especially in virtual environ	partial	infra	Partially implemented: PR microsoft/vscode-pylint#716 (merged 2026-03-02) added Python Environments extension as preferred interpreter resolver with legacy fallback. Significantly improves discovery but specific ENOENT and conda edge cases may remain. Required fix: Improve Python interpreter discove	microsoft/vscode-pylint#135, microsoft/vscode-pylint#613		microsoft/vscode-flake8#263, microsoft/vscode-flake8#409, microsoft/vscode-flake8#449, microsoft/vscode-flake8#555
microsoft/vscode-pylint	The Pylint extension fails to work in VS Code multi-root workspaces, either requiring all workspace folders to have a valid Python interpreter or failing to discover interpreters and run Pylint indepe	partial	infra	Partially implemented: LSP server manages per-workspace settings dict and resolves per-document. But extension.ts creates only one LanguageClient, not independent per-folder servers. Required fix: Add proper multi-root workspace support so the extension can independently resolve Python interpreters
microsoft/vscode-pylint	The Pylint extension's LSP client fails to establish or maintain a connection to the language server, producing "couldn't create connection" or "connection is erroring" messages that prevent linting f	no	infra	Required fix: Improve LSP server connection reliability with better error handling, retry logic, and connection lifecycle management. Reference PRs microsoft/vscode-black-formatter#449 and microsoft/vscode-black-formatter#410 for implementation approaches.	microsoft/vscode-pylint#532, microsoft/vscode-pylint#302		microsoft/vscode-black-formatter#449, microsoft/vscode-black-formatter#410
microsoft/vscode-pylint	Python and Pylint processes spawned by the extension are not properly terminated when VS Code closes, leaving orphan processes that consume system resources indefinitely.	partial	infra	Partially implemented: deactivate() stops LSP client; lsp_jsonrpc.py has atexit handler for subprocess cleanup; on_exit/on_shutdown call shutdown_json_rpc(). Basic cleanup exists but no forceful kill or orphan detection. Required fix: Implement proper process cleanup on extension deactivation and VS			microsoft/vscode-isort#224
microsoft/vscode-pylint	The Pylint extension silently fails when Pylint is misconfigured, missing required plugins, or running an unsupported version, giving users no indication that linting is not working.	partial	infra	Partially implemented: Version checking exists in _log_version_info(). Notification infrastructure exists (showNotifications setting). But pylint stderr (config errors, missing plugins) only goes to Output channel, not user notifications. Required fix: Surface Pylint configuration errors, missing pl	microsoft/vscode-pylint#80, microsoft/vscode-pylint#99, microsoft/vscode-pylint#297
microsoft/vscode-pylint	The Pylint extension only lints the currently open file, with no option to lint the entire project or workspace at once to find all issues across the codebase.	no	uncategorized	Required fix: Add support for running Pylint across all files in the project/workspace and reporting diagnostics for the entire codebase, not just the active editor. Reference PR microsoft/vscode-mypy#108 for an implementation approach.	microsoft/vscode-pylint#79		microsoft/vscode-mypy#108
microsoft/vscode-pylint	Running Pylint via the VS Code extension produces different diagnostics than running it directly from the command line, causing confusion about which results are correct.	partial	infra	Partially implemented: CWD is configurable with extensive variable substitution in get_cwd(). PYTHONPATH set for path/rpc modes. But --from-stdin mode and env differences may cause CLI discrepancies. Required fix: Ensure the extension invokes Pylint with the same working directory, environment varia
microsoft/vscode-pylint	The Pylint extension does not respect the python.envFile VS Code setting or .env files, causing Pylint to fail on import resolution when environment variables like PYTHONPATH are configured there.	no	infra	Required fix: Implement support for reading and applying environment variables from the python.envFile setting and .env files when launching the Pylint server process.	microsoft/vscode-pylint#433, microsoft/vscode-pylint#559
microsoft/vscode-pylint	The Pylint extension fails to process files or projects that involve symbolic links, raising ValueError exceptions or silently skipping symlinked files and directories.	partial	infra	Partially implemented: lsp_server.py uses pathlib.Path.resolve() for document paths (line 946) and lsp_utils.py normalize_path() uses .resolve(). Symlinks are followed for path resolution but no specific ValueError fix. Required fix: Fix file path resolution to properly handle symbolic links by reso			microsoft/vscode-black-formatter#460, microsoft/vscode-black-formatter#4215, microsoft/vscode-mypy#396
microsoft/vscode-pylint	The Pylint extension produces JavaScript errors or unhandled promise rejections visible in the VS Code Developer Tools console, indicating bugs in the extension's client-side TypeScript code.	no	infra	Required fix: Investigate and fix the client-side code errors surfaced in the Developer Tools console (typically unhandled promise rejections or type errors in the extension host). This issue hasn't been reported yet in vscode-pylint but exists in other repos (e.g., microsoft/vscode-black-formatter#
microsoft/vscode-pylint	The Pylint extension significantly slows down file save operations, with on-save linting taking many seconds to complete and blocking the editor workflow.	no	infra	Required fix: Optimize the on-save linting pipeline to reduce latency, such as debouncing rapid saves, running Pylint asynchronously without blocking the save, or avoiding redundant full-file relints on each save.	microsoft/vscode-pylint#454
microsoft/vscode-pylint	The Pylint extension does not support reporting lint issues for unopened files in the VS Code Problems panel, limiting visibility of project-wide code quality problems.	no	tool-specific	Required fix: Add a diagnostic reporting mode that runs Pylint across workspace files and surfaces issues in the VS Code Problems panel for project-wide visibility. This issue hasn't been reported yet in vscode-pylint but exists in other repos (e.g., microsoft/vscode-black-formatter#164, microsoft/v

[edvilme]

Phase 2: Test Coverage Audit

Methodology

1. Catalogued 173 relevant merged PRs across 5 extensions (excluding dependabot, CI/CD, version bumps)
2. For the 48 PRs that added tests, extracted specific test methods from diffs in path:method format
3. For the 125 PRs without tests, searched each repo's test suite for existing coverage of the changed functionality
4. Classified each PR as covered (6), partial (28), or uncovered (91 — of which 77 are infra/non-testable)
5. Filtered to 31 actionable items (28 partial + 3 uncovered runtime) that need test improvements before extraction

Untested Functionality

These PRs introduced bug fixes or features that lack adequate test coverage. Tests should be added before extracting shared code into the monorepo package.

PR	Untested functionality description	Missing tests
microsoft/vscode-black-formatter#496	Add logging to make it easier to find settings issues	Changes src/common/settings.ts (adds resolveVariables validation logging, traceInfo for workspace/global settings) and bundled/tool/lsp_server.py (updates log messages in initialize). settings.unit.test.ts exercises getWorkspaceSettings and resolveVariables code paths but does not verify the new validation error on non-string values or the space-in-args warning. formatting tests exercise lsp_server.initialize but do not check log output. The added logging behavior itself is not validated.
microsoft/vscode-black-formatter#557	fix: bug where successive python changed events trigger creating multiple servers	Changes src/common/python.ts, server.ts, settings.ts, utilities.ts, constants.ts, and extension.ts to fix race condition with multiple server instances. Existing tests cover individual modules (python, settings, utilities, configWatcher) but do not test the specific race condition scenario where rapid successive Python environment change events create duplicate servers. The core concurrency fix in extension.ts is not exercised by any test.
microsoft/vscode-black-formatter#637	Sync with template: Fix duplicate server handlers on concurrent restarts	Changes src/common/server.ts (moves _disposables cleanup outside if block) and src/extension.ts (wraps lsClient.stop() in try/catch). configWatcher tests verify server restart behavior but do not specifically test the _disposables cleanup ordering or concurrent restart race conditions. The deactivate() try/catch in extension.ts is also untested.
microsoft/vscode-black-formatter#662	Replace hand-rolled typings with @vscode/python-environments npm package	Changes src/common/python.ts (getEnvironmentsExtensionAPI now uses @vscode/python-environments instead of manual extension activation) and removes src/typings/pythonEnvironments.d.ts. python.unit.test.ts tests getInterpreterDetails which calls getEnvironmentsExtensionAPI, but mocks may not fully exercise the new PythonEnvironments.api() code path vs the old extensions.getExtension() pattern.
microsoft/vscode-black-formatter#671	Use contextlib.suppress instead of try-except-pass	Changes lsp_utils.py (_run_module/_run_api) and lsp_jsonrpc.py (close/stop_all_processes). Formatting tests exercise _run_module/_run_api code paths in lsp_utils.py, but lsp_jsonrpc.py close() and stop_all_processes() are not directly tested. The refactor is purely stylistic (try/except to contextlib.suppress) so behavioral coverage from formatting tests provides reasonable confidence for lsp_utils changes.
microsoft/vscode-flake8#327	Use global settings for ignorePatterns default	The PR fixes _get_global_defaults() to read ignorePatterns from GLOBAL_SETTINGS instead of always defaulting to []. Tests test_ignore_patterns_match and test_ignore_patterns_no_match verify ignorePatterns filtering behavior via LSP initialization settings. However, they pass ignorePatterns explicitly in the initialization options rather than testing the GLOBAL_SETTINGS fallback path specifically, so the exact bug fix (reading from GLOBAL_SETTINGS when no workspace setting is present) may not be exercised.
microsoft/vscode-flake8#336	fix: Bug where successive python changed events trigger creating multiple servers	The PR adds restart debouncing logic in extension.ts (isRestarting flag + timer), refactors python.ts event handling (checkAndFireEvent, refreshServerPython, sameInterpreter), and moves getInterpreterFromSetting to utilities.ts. TS tests cover getInterpreterDetails and getServerCwd but do NOT test the debouncing/throttling logic in extension.ts or the new event deduplication in python.ts.
microsoft/vscode-flake8#367	Update to Pygls 2	The Pygls 2 migration updated lsp_server.py API calls (get_document->get_text_document, publish_diagnostics->text_document_publish_diagnostics, show_message_log->window_log_message, etc.). Python tests exercise the LSP handlers (didOpen, didSave, didClose, codeAction) which use the updated APIs. However, the logging API changes (log_to_output, log_error, log_warning, log_always) and error notification paths aren't directly verified by tests.
microsoft/vscode-flake8#401	Sync with template: Fix duplicate server handlers on concurrent restarts	The PR changes restartServer() in server.ts to move _disposables cleanup outside the lsClient guard, and wraps lsClient.stop() in deactivate() with try/catch. The existing server.unit.test.ts only tests getServerCwd, not restartServer() or the disposables cleanup logic. No tests cover the concurrent restart fix or deactivate error handling.
microsoft/vscode-flake8#428	Replace try-except-pass with contextlib.suppress	Linting tests exercise lsp_utils._run_module and lsp_jsonrpc indirectly through the LSP server. However, the specific error-handling refactor (try/except:pass -> contextlib.suppress) is a behavioral no-op and not directly tested for exception suppression paths.
microsoft/vscode-flake8#434	Replace hand-rolled typings with @vscode/python-environments npm package	TS tests cover getInterpreterDetails and interpreter resolution for both Python Environments and legacy extension. However, the specific API migration from hand-rolled typings to @vscode/python-environments npm package (e.g., PythonEnvironments.api() vs extensions.getExtension()) is not directly tested since the extension APIs are mocked.
microsoft/vscode-isort#519	Update minimum Python version to 3.10	PR changes PYTHON_MINOR from 8 to 10 in src/common/constants.ts and updates CI workflows/pipelines. python.unit.test.ts tests version rejection (uses 3.8.0 as unsupported, which is still below 3.10) and interpreter discovery. However, the test does not validate the new boundary (3.9 should now be rejected), and CI/CD pipeline changes (.github/workflows, build/*.yml, noxfile.py, runtime.txt) have no test coverage.
microsoft/vscode-isort#521	Update isort to 7.0.0 for Python 3.14 compatibility	PR bumps isort from 6.1.0 to 7.0.0 and MIN_VERSION in bundled/tool/lsp_server.py. test_sort.py exercises end-to-end import sorting which validates isort 7.0.0 works correctly. However, no test validates the MIN_VERSION check itself, and Python 3.14 compatibility (the main motivation) requires that specific runtime to verify.
microsoft/vscode-isort#522	Check for None on _run_tool_on_document	PR adds a None check in _formatting_helper (bundled/tool/lsp_server.py) before accessing result.stdout. test_sort.py exercises _formatting_helper through LSP organize-import (happy path), and runner.unit.test.ts covers error/null cases on the TS client side. However, the specific scenario (multi-root workspace where _run_tool_on_document returns None) is not directly tested.
microsoft/vscode-isort#541	Fix multiple isort handlers registered due to concurrent server restarts	PR modifies src/extension.ts adding serverEnabled support, subscription cleanup, and sortImports registration. ConfigWatcher tests cover server restart behavior and runner tests cover the sortImports runner, but the core fix (preventing duplicate handler registration, serverEnabled toggle lifecycle, subscription accumulation bug) in extension.ts has no direct tests.
microsoft/vscode-mypy#325	Use global settings for ignorePatterns default	Changed _get_global_defaults to read ignorePatterns from GLOBAL_SETTINGS. Ignore pattern tests exist but pass patterns via per-workspace init settings, not global settings. Global-to-workspace default inheritance is not tested.
microsoft/vscode-mypy#342	use correct capitalization of file paths to work around mypy issue	Changed document.path to pathlib.Path(document.path).resolve() for Windows capitalization. Linting and path tests exercise the code path but do not verify Windows path casing normalization.
microsoft/vscode-mypy#344	update capitalization of cwd to match file path	Added pathlib.Path(cwd).resolve() for Windows path capitalization. Tests exercise the code path but CI runs on Linux where capitalization is not an issue.
microsoft/vscode-mypy#346	fix: bug where successive python changed events trigger creating multiple servers	Added debounce logic in extension.ts, event deduplication in python.ts, moved getInterpreterFromSetting. Python and settings tests exist but do not test the debounce behavior or multiple rapid restart prevention.
microsoft/vscode-mypy#347	Add dmypy status file setting	Added daemonStatusFile setting to settings.ts and lsp_server.py. Settings TS tests exist but do not assert the new daemonStatusFile property. Non-daemon test exercises dmypy args but uses default empty status file, not a custom one.
microsoft/vscode-mypy#357	When cwd config option is nearestConfig, look for all of mypy.ini, .mypy.ini, pyproject.toml, setup.cfg	Extended nearestConfig to search for .mypy.ini, pyproject.toml, setup.cfg. Existing tests cover nearestConfig but only create mypy.ini; no tests verify .mypy.ini, pyproject.toml, or setup.cfg detection.
microsoft/vscode-mypy#375	Fix: parse mypy diagnostics from stderr in non_interactive mode	Changed _linting_helper to combine stdout+stderr for diagnostic parsing. Linting and non-daemon tests exercise the pipeline but none produce diagnostics on stderr to verify the combined parsing works.
microsoft/vscode-mypy#442	Sync with template: Fix duplicate server handlers on concurrent restarts	Changed src/common/server.ts (disposables cleanup) and src/extension.ts (try/catch in deactivate). No tests exist for server restart or deactivation logic.
microsoft/vscode-mypy#467	Replace hand-rolled typings with @vscode/python-environments npm package	Replaced extensions.getExtension() with PythonEnvironments.api() from @vscode/python-environments. TS tests cover interpreter resolution but test stubs may use old getExtension pattern rather than new PythonEnvironments.api() import.
microsoft/vscode-mypy#470	Use contextlib.suppress instead of try-except-pass in lsp_utils.py	Changed _run_api in lsp_utils.py to use contextlib.suppress(SystemExit). Tests exercise _run_api through the linting pipeline and non-daemon mode, but none specifically test the SystemExit suppression behavior.
microsoft/vscode-pylint#684	Align PYTHON_MINOR constant with CI minimum of 3.10	Changes PYTHON_MINOR from 9 to 10 in src/common/constants.ts. The python.unit.test.ts has version rejection tests that import from constants and test the version-checking logic in python.ts, which uses PYTHON_MINOR. However, these tests mock the Python version returned by the extension API rather than testing specific version boundaries, so the exact threshold change (3.9->3.10) may not be directly validated.
microsoft/vscode-pylint#687	Add loading indicator	Changes lsp_server.py (adds pylint/lintingStarted and pylint/lintingFailed notifications, modifies score notification to always fire), server.ts (adds handlers for new notifications), and status.ts (loading/error UI states). Score notification tests cover the modified pylint/score notification path and verify structure. Linting tests exercise _linting_helper indirectly. However, the NEW pylint/lintingStarted and pylint/lintingFailed notifications have no dedicated tests. The TypeScript status bar loading/error display logic in status.ts and the new handlers in server.ts are entirely untested.
microsoft/vscode-pylint#705	Sync with template: Fix duplicate server handlers on concurrent restarts	Changes src/common/server.ts (disposables cleanup moved outside if-block) and src/extension.ts (try/catch around lsClient.stop in deactivate). No TypeScript tests exist for restartServer() or deactivate() functions. The changes affect server lifecycle management which has no test coverage.
microsoft/vscode-pylint#706	Sync with template: Fix duplicate server handlers on concurrent restarts	Changes src/common/settings.ts (adds serverEnabled to checkIfConfigurationChanged and new getServerEnabled function) and src/extension.ts (adds serverEnabled check in restart flow). Settings tests cover getWorkspaceSettings and isLintOnChangeEnabled but do NOT test checkIfConfigurationChanged or the new getServerEnabled function. The extension.ts restart logic with serverEnabled guard has no test coverage.
microsoft/vscode-pylint#732	Use contextlib.suppress instead of try-except-pass	The changed files (lsp_jsonrpc.py, lsp_utils.py) are exercised indirectly by all LSP-based tests since they provide the JSON-RPC transport and module-running utilities. However, no tests specifically target the error-suppression paths (stream close failures, SystemExit suppression). The refactoring is purely stylistic (try/except/pass to contextlib.suppress) so the existing integration tests validate that normal behavior is preserved.
microsoft/vscode-pylint#737	Replace hand-rolled typings with @vscode/python-environments npm package	python.unit.test.ts directly tests getInterpreterDetails from src/common/python.ts which was the main file changed. The 'Finds interpreter using Python Environments extension' test exercises the environments API path. However, tests mock the extension APIs, so the new PythonEnvironments.api() call from @vscode/python-environments is not directly validated -- only the downstream logic is covered.

Summary by Repo

Repo	Items
microsoft/vscode-black-formatter	5
microsoft/vscode-flake8	6
microsoft/vscode-isort	4
microsoft/vscode-mypy	10
microsoft/vscode-pylint	6
Total	31