Repository navigation
Make typechecking on by default for non-VSCode editors #1340
Description
Describe the Bug
Hi, I'm trying to run pyrefly in neovim and not getting any type checking. Here are the error logs with timestamp and level removed). I've attached debug logs at the bottom as well
"rpc" "pyrefly" "stderr" "starting generic LSP server\n"
"rpc" "pyrefly" "stderr" "Reading messages\n"
"rpc" "pyrefly" "stderr" "Request textDocument/semanticTokens/full (2) is canceled due to subsequent mutation\n"
"rpc" "pyrefly" "stderr" "Could not decode `LspConfig` from Null, skipping client configuration request: invalid type: null, expected struct LspConfig.\n"
Setting NVIM_APPNAME means my config comes from the below directory
# > echo $NVIM_APPNAME
nvim-pyrefly-reproducer
# > pwd
/home/ajc/.config/nvim-pyrefly-reproducer
# > ls
init.lua test.py
# > cat init.lua
vim.lsp.config['pyrefly'] ={
cmd = { 'pyrefly', 'lsp' },
filetypes = { 'python' },
root_markers = {
'pyrefly.toml',
'pyproject.toml',
'setup.py',
'setup.cfg',
'requirements.txt',
'Pipfile',
'.git',
},
on_exit = function(code, _, _)
vim.notify('Closing Pyrefly LSP exited with code: ' .. code, vim.log.levels.INFO)
end,
}
vim.lsp.set_log_level("debug")
vim.lsp.enable("pyrefly")
I open test.py, and there's no type checking for my obvious errors
def add(a: int, b: int) -> int:
return a + b
add("a","b")Running on linux. Pyrefly installed through uv tool install:
# > nvim --version
NVIM v0.11.4
Build type: RelWithDebInfo
LuaJIT 2.1.1753364724
Run "nvim -V1 -v" for more info
# > pyrefly --version
pyrefly 0.37.0
I've attached my full lsp.log from opening the file
lsp.log
Sandbox Link
No response
(Only applicable for extension issues) IDE Information
No response
Activity
Emilv2 commentedon Oct 20, 2025
You need a config for pyrefly in
pyrefly.tomlorpyproject.tomlto enable type checking: https://github.com/facebook/pyrefly/releases/tag/0.32.0 (or set displayTypeErrors": "force-on" but I haven't figured out how do that in neovim). IMHO there should at least be a logging message reporting this, it took me also a while to figure out what was happening.ajc133 commentedon Oct 21, 2025
Running
pyrefly initdid indeed solve my issue. Thank you. I only opened up this page and went straight to the neovim heading, in case that anecdata helps improve the docs . If I had read the beginning, I may have figured it out.Perhaps the neovim heading can suggest the user's run
pyrefly init🤷also yes, some command line flag to turn on type checking might be welcome for users that don't want to have a config anywhere
samwgoldman commentedon Oct 21, 2025
Does the configuration suggested in this comment enable type errors without a config file? #1240 (comment)
Please let me know if it works for you and I will update the docs to mention it.
ajc133 commentedon Oct 22, 2025
Yes, that works, thanks for the link! So with nvim-lspconfig installed, the minimal config block looks like this
ajc133 commentedon Oct 22, 2025
At the risk of sounding obnoxious, it's too bad that type checking is disabled by default, especially since this is billed as a type checker and pyright-langserver does it by default.
I'm sure there's there's been so much breath spent on this already though. Thanks again for the help!
yangdanny97 commentedon Oct 22, 2025
Iirc the reason the default is set this way is because that's what Pylance does in VS Code. But I think what we do in VS Code doesn't necessarily have to be the same as what we do in other editors.
[-]neovim 0.11.4 - 'Could not decode `LspConfig` from Null, skipping client configuration request: invalid type: null, expected struct LspConfig.'[/-][+]Make typechecking on by default for non-VSCode editors[/+]megapixel-code commentedon Feb 9, 2026
I also do think the type checking should be on by default, I left my config without this setting thinking this was a problem with pyrefly because it was so new hoping to get an update with this fix.
It's now fixed on my computer but maybe some less finicky users might just abandon this lsp for this reason.
yangdanny97 commentedon Feb 10, 2026
Thanks for the input!
We plan to gradually enable certain type errors by default over time, using a data-driven approach to decide what should be on-by-default, off-by-default, or strict-mode only.
Recently, as of v0.52.0, we've taken a tiny step in that direction and enabled semantic syntax & parsing errors by default for all editors.
Add github workflow for v1 issue ranking
Add github workflow for v1 issue ranking