v1.21.1 (pyright 1.1.389)

What's Changed

• Update License Info with Well-known OSA MIT License Classifier by @macserv in #857
• fix crash when project contains a package.json with "type": "module" by @DetachHead in #862
• fix unknown imports being incorrectly highlighted as a variable by @DetachHead in #863
• make properties with no setter highlighted as readonly in the semantic highlighter by @DetachHead in #864
• update upstream pyright version to 1.1.389 by @DetachHead in #872

New Contributors

• @macserv made their first contribution in #857

Full Changelog: v1.21.0...v1.21.1

v1.21.0 (pyright 1.1.388)

What's Changed

new "hint" diagnostic category

previously, in addition to the standard diagnostic categories "error" and "warning", some diagnostic rules such as reportUnreachable and reportDeprecated supported special diagnostic categories like "unreachable" and "deprecated" respectively, which would show as a hint in your editor instead of an error:

the issue with these hints is that they only make sense for diagnostic rules that relate to unnecessary or deprecated code. but there was no way to set a hint-level diagnostic for other diagnostic rules. the configuration for these hints was also needlessly confusing (eg. "unreachable" and "unused" look exactly the same). they also didn't make sense for editors that don't support diagnostic tags.

this release introduces the new "hint" diagnostic category to replace the "deprecated", "unused" and "unreachable" categories, which are now deprecated. for most rules, they will display as a hint:

but for rules where it makes sense to do so, the appropriate diagnostic tag (unnecessary or deprecated) will be applied automatically. this also allows all baselined diagnostics to be displayed as a hint, rather than just ones that can be considered unreachable/unnecessary.

for more information, see the docs

(implemented in #845)

other changes

• fix locale parsing on Linux by @arenekosreal in #834
• Fix file rename check running on files that aren't part of the workspace by @DetachHead in #843
• fix inlay hints appearing on super() calls by @DetachHead in #847
• update upstream pyright version to 1.1.388 by @DetachHead in #851

New Contributors

• @arenekosreal made their first contribution in #834

Full Changelog: v1.20.0...v1.21.0

v1.20.0 (pyright 1.1.387)

What's Changed

inlay hints for generics

these can be enabled using the new basedpyright.analysis.inlayHints.genericTypes setting:

• when instantiating classes (#818)
  
• Final and ClassVar annotations (#809)
  

note that it's disabled by default because the information it provides is often redundant when basedpyright.analysis.inlayHints.variableTypes is enabled:

new diagnostic rule: reportUnannotatedClassAttribute

pyright does not warn when a member of a class that doesn't have a type annotation is overridden with an incompatible type:

class A:
    value = 1

class B(A):
    value = None # no error, even though the type on the base class is `int` and the type here is `None`

this decision seems to have been made for performance reasons, which is fair enough. but because it's unsafe, there should be a check that enforces type annotations on class attributes (unless the class is decorated with @final). the reportUnannotatedClassAttribute rule will do just that:

class A:
    value = 1 # error: Type annotation for attribute `value` is required because this class is not decorated with `@final` 

(implemented in #812)

merge upstream & experimental inline TypedDict update

• update upstream pyright version to 1.1.387 (#829)
• previously, we supported an experimental syntax for defining inline TypedDicts:

  foo: dict[{"foo": int}] = {"foo": 1}

  this used to be supported in pyright but was removed a few months ago because it was never made into a PEP. i decided to keep the feature in basedpyright, however a draft PEP was created for it recently, which resulted in the feature being added back in this release of pyright, but with a different syntax:

  + foo: TypedDict[{"foo": int}] = {"foo": 1}

• to reduce confusion, i've removed support for the old dict[{"foo": int}] syntax. from now on any deviations we make from the standard will be configured using a separate option instead of using pyright's enableExperimentalFeatures setting, which is now disabled by default like it is in pyright (#831)

other changes

• fix crash when pyproject.toml contains an emoji by @DetachHead in #822
• fix import suggestion code actions not working when no workspace is open by @DetachHead in #824
• fix hang when installing basedpyright from github url using uv by @DetachHead in #825
• Chinese (Simplified) localization update (2024.10) by @NCBM in #767
• Remove redundant bullet point in docs by @tylerlaprade in #811

New Contributors

• @tylerlaprade made their first contribution in #811

Full Changelog: v1.19.1...v1.20.0

v1.19.1 (pyright 1.1.386)

What's Changed

• fix typeCheckingMode still defaulting to "all" in the language server when there's no config file by @DetachHead in #791
• prevent inlay hints from appearing on enum members by @DetachHead in #793
• update upstream pyright version to 1.1.386 by @DetachHead in #805
  • the new version of the toml parser included in this release was busted - see microsoft/pyright#9296 (and i think it also might have a memory leak on windows?), so i switched it to use js-toml instead

Full Changelog: v1.19.0...v1.19.1

v1.19.0 (pyright 1.1.385)

What's Changed

fixing the overly strict default typeCheckingMode

it may be an unpopular opinion, but i believe that type checkers/linters should be as strict as possible by default - to ensure that the user is made aware of all potential issues in their code, and that they are the ones responsible for making the conscious decision to reduce the strictness if they wish. i expand on my perspective in this comment.

the reality though is that it's really annoying for the user to see the same red line on both an unknown import and an unused import.

basedpyright 1.19.0 introduces a new default typeCheckingMode called "recommended", which sets most of the stricter rules to be reported as a warning instead of an error. we've also added a new setting called failOnWarnings for the CLI which is enabled by default in this mode.

i believe this addresses the concerns some users have had regarding the default settings, while still ensuring that the user is made aware of all the checks basedpyright has to offer.

you can read more about the diagnostic rulesets in the docs.

(implemented in #759)

other changes

• add new reportImplicitAbstractClass diagnostic rule by @DetachHead & @KotlinIsland in #774
• generate builtin docstrings for python 3.13 by @DetachHead in #768
• update documentation for editables to clarify that it's talking about build backends rather than frontends by @DetachHead in #770
• Add link to pylance issues to pylance features page by @xixixao in #777
• update upstream pyright version to 1.1.385 by @DetachHead in #782

New Contributors

• @xixixao made their first contribution in #777

Full Changelog: v1.18.4...v1.19.0

v1.18.4 (pyright 1.1.384)

What's Changed

language server

• add settings to disable each type of inlay hint by @DetachHead in #738, #740
• don't show inlay hints for positional arguments by @DetachHead in #741
• only show exact matches in import suggestion code actions by @DetachHead in #748

documentation

• Fix diagnostic rule documentation links on old versions of basedpyright by @DetachHead in #737
• various improvements and fixes to the docs by @DetachHead in #743
  • fix broken links
  • update some wording that implied the only way to run basedpyright in an IDE is by using the vscode extension
  • add some editor-specific examples of how to configure the language server

other changes

• update upstream pyright version to 1.1.384 by @DetachHead in #758

Full Changelog: v1.18.3...v1.18.4

v1.18.3 (pyright 1.1.383)

What's Changed

• update upstream pyright version to 1.1.383 by @DetachHead in #730
• fix some bugs with the automatic baseline updating by @DetachHead in #722

Full Changelog: v1.18.2...v1.18.3

v1.18.2 (pyright 1.1.382)

What's Changed

• fix hyperlinks to the docs from diagnostics in the language server by @DetachHead in #717
• fix issue where an empty baseline file was being automatically created when running basedpyright from the CLI by @DetachHead in #718

Full Changelog: v1.18.1...v1.18.2

v1.18.1 (pyright 1.1.382)

What's Changed

• fix baseline when running in multithreaded/background analysis mode by @DetachHead in #702
• improve baseline matching by using a diff algorithm and comparing the number of lines the diagnostic covers by @DetachHead in #708
• new documentation site by @DetachHead in #699, #712, #715, #716

Full Changelog: v1.18.0...v1.18.1

v1.18.0 (pyright 1.1.382)

What's Changed

baseline support (beta) 🚀🚀🚀

have you ever wanted to adopt a new tool or enable new checks in an existing project, only to be immediately bombarded with thousands of errors you'd have to fix? baseline solves this problem by allowing you to only report errors on new or modified code. it works by generating a baseline file keeping track of the existing errors in your project so that only errors in newly written or modified code get reported.

to enable baseline, run basedpyright --writebaseline in your terminal or run the "basedpyright: Write new errors to baseline" task in vscode. this will generate a ./basedpyright/baseline.json for your project. you should commit this file so others working on your project can benefit from it too.

this file gets automatically updated as errors are removed over time in both the CLI and the language server. if you ever need to baseline new errors or an error that resurfaced because you've modified the same line of code it was on, just run that command again.

heavily inspired by basedmypy

more info is available in the documentation

(implemented in #608)

other changes

• Chinese translations fix by @sena-nana & @NCBM in #598
• update upstream pyright version to 1.1.382 by @DetachHead in #694

New Contributors

• @sena-nana made their first contribution in #598

Full Changelog: v1.17.5...v1.18.0