Overview
Phase 4 normalization for isort as part of the shared package extraction effort.
Tracking issue: microsoft/vscode-python-tools-extension-template#290
What is normalization?
All 5 Python tool extensions (black-formatter, flake8, isort, mypy, pylint) were originally scaffolded from the same template and share ~70% of their code. Over time, each repo diverged: functions were renamed, parameters changed, utilities landed in different files, and features were added to some repos but not others.
Normalization is the process of re-aligning these codebases so that:
- Equivalent functions have identical signatures — e.g.,
normalize_path() should accept the same parameters everywhere
- Equivalent functionality lives in the same file — e.g., if
_get_settings_by_path() exists in 4 repos' lsp_server.py, the 5th repo should have it too
- Missing shared features are backported — e.g., localization files that exist in 3 repos should be added to the other 2
Why is this needed?
The end goal (template#290) is to extract the shared code into a reusable package (vscode-python-tool-lsp). For this to work, we need a clean 1:1 mapping between repo code and package code. If function signatures differ or utilities live in different files, extraction becomes a messy per-repo special case instead of a clean "delete shared file, import from package" operation.
All changes are backwards-compatible — adding optional parameters with defaults, aligning function signatures, and moving code to the correct files. No behavioral changes.
Tasks
Structural Alignment (methods in the right files)
Python Normalizations (bundled/tool/)
TypeScript Normalizations (src/common/)
Feature Parity
None — isort already has full feature parity.
PR Strategy
Each task gets its own branch and PR for focused review:
- Branch naming:
phase4/<task-slug>
- All changes are backwards-compatible
- Tests must pass before merge
Overview
Phase 4 normalization for isort as part of the shared package extraction effort.
What is normalization?
All 5 Python tool extensions (black-formatter, flake8, isort, mypy, pylint) were originally scaffolded from the same template and share ~70% of their code. Over time, each repo diverged: functions were renamed, parameters changed, utilities landed in different files, and features were added to some repos but not others.
Normalization is the process of re-aligning these codebases so that:
normalize_path()should accept the same parameters everywhere_get_settings_by_path()exists in 4 repos'lsp_server.py, the 5th repo should have it tooWhy is this needed?
The end goal (template#290) is to extract the shared code into a reusable package (
vscode-python-tool-lsp). For this to work, we need a clean 1:1 mapping between repo code and package code. If function signatures differ or utilities live in different files, extraction becomes a messy per-repo special case instead of a clean "delete shared file, import from package" operation.All changes are backwards-compatible — adding optional parameters with defaults, aligning function signatures, and moving code to the correct files. No behavioral changes.
Tasks
Structural Alignment (methods in the right files)
update_environ_path()tolsp_server.py(currently missing)_log_version_info()— removesettingsparameter to match other reposPython Normalizations (
bundled/tool/)lsp_jsonrpc.py— changeExceptiontoConnectionErrorin RPC error handlingresolve_symlinks=Trueparameter tonormalize_path()inlsp_utils.pyis_match(patterns, file_path, workspace_root=None)tolsp_utils.py(currently missing)exit_code=Nonefield toRunResultdataclass inlsp_utils.pylsp_runner.pyos.getcwd()insys.path— align or documentTypeScript Normalizations (
src/common/)expandTilde()export fromsettings.tstoenvFile.tsgetDocumentSelector()— add notebook scheme support (or parameterize)configWatcher.tsto robust disposal pattern (error handling + disposed flag)settings.tsto baseISettingsinterface with shared fieldsserver.tsviaToolConfig.hooksinterfaceextension.tsto thin wrapper (depends on 4.1e + 4.1f)Feature Parity
None — isort already has full feature parity.
PR Strategy
Each task gets its own branch and PR for focused review:
phase4/<task-slug>