Pyrefly 1.2 combines a type checker and language server
Pyrefly 1.2 checks Python types from the command line and exposes the same analysis through the Language Server Protocol. The editor side includes completion, navigation, hovers, rename, semantic highlighting, and inlay hints. Official extensions cover VS Code and Open VSX, while the documentation lists Neovim, Zed, and other clients. The project calls its current line stable, which makes it a realistic candidate for team evaluation rather than a research-only checker.
The repository is correspondingly large: our checkout contained 9,972 files, about 588,137 lines of source, and 71.1 MB before the build. A Rust workspace holds the checker, type model, configuration, bundled stubs, sandbox, and utility crates. Separate trees cover conformance data, command-line tests, language-server tests, tensor-shape work, and the documentation site. That breadth explains both the product coverage and the amount of code a contributor must understand.
What happened when we ran it
Our sandbox installed 408 Rust packages in 34 seconds and built Pyrefly in 248 seconds. The checkout ran in an unprivileged Rust container with 3 CPUs and 12 GB of RAM. Installation and compilation both succeeded. The build result proves commit d8bef69 compiled in that environment. Our run did not benchmark Pyrefly against Instagram, PyTorch, or another checker.
The test command reached our 900-second cap and timed out. Its final lines showed Polars dataframe cases still reporting ok, including schema, null filling, filtering, renaming, selecting, and column-addition cases. The tail contained no assertion failure or panic, so the precise finding is a timeout, not a failed test. Our scan found 32 CI workflow files, a tests directory, and no Dockerfile. The complete upstream pass count is unknown from this run.
Version 1.2 eases migration without promising identical results
Pyrefly 1.2 looks for mypy.ini, pyrightconfig.json, or matching pyproject.toml sections when a project has no native configuration. It can translate those settings in memory and fall back to a basic preset that reports a smaller set of high-confidence errors. Running pyrefly init writes a native configuration. The migration guide recommends keeping both checkers in CI until the team has reviewed differences, which is the right adoption order for a tool that can change whether a build passes.
The 408-package workspace we installed supports two ways to handle existing findings. Suppression comments keep exceptions beside the affected code, while a baseline records current errors outside the source so CI can focus on new ones. Both lower the first-day cost on a large codebase. Neither proves that the converted configuration means the same thing as the old one. The guide explicitly says some incumbent settings have no equivalent and unrecognized settings can be skipped without warning.
Monthly minor releases can change the diagnostic result
The README says Pyrefly publishes minor versions monthly and patches between them when needed. It also says the project does not follow strict semantic versioning: minor releases carry larger changes, but any version may introduce type errors or other breaking behavior. That policy is unusually candid. It also means a floating CI install can turn yesterday's clean project red. Pin the package, read behavior changes, and upgrade on a branch where suppressions and config changes can be reviewed.
Our 248-second build and 900-second test timeout make upstream contribution more demanding than installing the published command. Development needs a Rust toolchain, while the all-in-one script requires Python 3.9 or newer and updates conformance outputs. The contributing guide asks people to claim an issue, add tests in the appropriate suite, pass CI, and sign Meta's contributor license agreement. Small checker changes still sit inside a repository with several test systems and generated conformance data.
Stable status still leaves Python edge cases open
Release 1.2.0 arrived on July 31, 2026 with 901 commits from 59 contributors. Its notes say 137 bug issues were closed and describe work across typing behavior, libraries, the language server, error reports, coverage, configuration, stub generation, and Bazel support. GitHub recorded the last push on August 31, 2026, plus 6,920 stars and 696 open issues and pull requests. The issue count is combined, but recent reports and same-day pushes show active development rather than neglect.
The 900-second ceiling in our run did not expose a correctness failure, while the open tracker supplies concrete cases to evaluate. Issue 4752 reports an exhaustive class-pattern match being marked incomplete on current main. Issue 4302 describes a Windows project include pattern being treated as excluded. Both provide reproductions and concern the checker behavior discussed here. A migration pilot should include each project's decorators, framework models, config paths, platform guards, and strictness settings instead of relying on a small sample file.
A 248-second source build favors packaged adoption
Mypy is the conservative choice when existing plugins and familiar diagnostics carry more weight than editor unification. Pyright remains compelling for teams already using its behavior through editor tooling. Astral's ty is the closest new Rust alternative and should be compared on the same project instead of by marketing speed claims. Pyrefly earns its trial through the combined CLI and language server, migration commands, framework support, and published stable status.
Our source build completed in 248 seconds, while the full test command exceeded 900 seconds. Most adopters should use the packaged release and reserve source work for teams prepared for Rust and the larger suite. Run Pyrefly beside the incumbent checker, pin version 1.2.0 or a chosen successor, and review every converted setting. The tool is ready for a measured migration; the release policy and open edge cases make an overnight replacement hard to defend.