Cloud Parts

basedpyright

A community fork of Pyright that is stricter by default, installs from PyPI without a separate Node.js, and brings Pylance-only editor features to any editor.

What it is
Linters, formatters and type checkers (type checkers)
Part of
Fork of Pyright
Type
Open source
Made by
DetachHead and contributors (community project)
License
MIT
Facts checked
9 October 2026
Website Source code

What it is

basedpyright merges every Pyright release, usually on the day it comes out (1.40.2 is based on Pyright 1.1.414), and changes what surrounds the checker. It is published on PyPI with Node.js bundled through a wheel, so uv add --dev basedpyright is all a Python project needs, and its VS Code extension uses the version installed in the project, so the editor and CI report the same errors. The default typeCheckingMode is recommended, which turns on every rule, reports the less severe ones as warnings and still fails the CLI on warnings. It adds rules Pyright lacks, such as reportAny, reportUnusedParameter and reportIgnoreCommentWithoutRule, assumes code may run on any operating system, and finds a project’s ./.venv without configuration.

Two features target real codebases. A baseline (basedpyright --writebaseline) records today’s errors in .basedpyright/baseline.json, so only new or changed code is reported and the file shrinks as errors are fixed; the idea came from basedmypy. And the language server re-implements features Microsoft keeps in its closed-source Pylance extension, such as import suggestions as quick fixes and Jupyter notebook support, for any editor that speaks the Language Server Protocol, including VS Code forks served by Open VSX.

Why teams pick it

  • Pylance-style editor features in any LSP editor, not just Microsoft’s VS Code
  • Installs and pins like any Python dev dependency, with no separate Node.js install, and the editor uses that same version
  • Baselines let a team adopt strict rules in an old codebase without fixing every existing error first
  • Extra rules and stricter defaults catch problems, such as leaking Any types, that Pyright’s defaults let through

Watch out for

  • It is Pyright underneath, so it has the same engine and speed; and the PyPI package still runs it on a bundled Node.js, pulled in as a separate wheel
  • The default recommended mode is noisy on an existing project until you tune it or write a baseline
  • A community project with no company behind it, which has to keep pace with Microsoft’s upstream releases
  • Different defaults from Pyright and Pylance mean teammates on Pylance can see different results for the same code

How it fits with other technologies

Default rules, then a baseline (basedpyright 1.40.2, no configuration) · bash

uv run basedpyright
# …/shop/src/shop/orders.py:16:18 - error: Type "int" is not assignable to declared type "str"
# …/shop/src/shop/orders.py:20:11 - warning: Type annotation is missing for parameter "raw" (reportMissingParameterType)
# ...
# 2 errors, 4 warnings, 0 notes      (exit code 1: warnings fail too)

uv run basedpyright --writebaseline   # commit the file it writes
# updated ./.basedpyright/baseline.json with 6 errors (went up by 6)

# later, someone adds:  def late(x: int) -> str: return x
uv run basedpyright
# …/shop/src/shop/orders.py:25:12 - error: Type "int" is not assignable to return type "str"
#     "int" is not assignable to "str" (reportReturnType)
# 1 error, 0 warnings, 0 notes      (only the new problem is reported)

See it in a real stack

No architecture uses basedpyright yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2024–2026

Pyright is open source, but in VS Code Microsoft steers users to Pylance, a closed-source extension with extra features that only works in Microsoft’s own VS Code. Pyright itself ships on npm, so Python projects needed Node.js to run it, and a VS Code extension that updated on its own could report different errors from the version pinned in CI.

The GitHub user DetachHead forked Pyright to fix those gaps, publishing the first pre-release with a VS Code extension in January 2024 and 1.0.0 ten days later, with a first-party PyPI package, an extension that pins itself to the project’s version and a new reportUnreachable rule. Baselines, modelled on basedmypy’s, arrived in 1.18 in September 2024.

Since then the fork has tracked every upstream release while adding rules, smarter narrowing of generic types and re-implemented Pylance features, and it is distributed through PyPI, the VS Code Marketplace, Open VSX, Homebrew and Sublime Text’s Package Control.

Why it’s built this way

Stay a fork that merges every upstream release
Rebasing on each Pyright tag keeps type-checking behaviour current and lets the project spend its effort on defaults, rules and editor features.
Strict by default
The maintainers believe users should see every available rule and opt out deliberately; warnings for less severe rules and baselines soften the impact.
Ship on PyPI with Node bundled
Python developers shouldn’t need a JavaScript package manager to type-check Python, and a PyPI package can be pinned with the rest of the project’s dev tools.
Re-implement Pylance features in the open
Features locked in a closed extension can’t reach other editors or VS Code forks, so the fork rebuilds them in its own language server.

Timeline

  1. 2024

    January: first pre-release, then 1.0.0 with a PyPI package

  2. 2024

    September: baseline support (1.18)

  3. 2024

    November: stricter narrowing of generic types (1.22)

  4. 2026

    October: 1.40.2, based on Pyright 1.1.414

Sources8 · facts checked 9 October 2026

Improve this page on GitHub