jose-elias-alvarez / nvim-lsp-ts-utils

Utilities to improve the TypeScript development experience for Neovim's built-in LSP client.
The Unlicense
438 stars 18 forks source link

[BUG] Default configuration seems to cause validation errors on every file load #60

Closed samtgarson closed 3 years ago

samtgarson commented 3 years ago

FAQ

Issues

Neovim Version

v0.5.0 Release

Steps to reproduce

Expected behavior

Actual behavior

null-ls: failed to run generator: ...rs/sam/.vim/plugged/null-ls.nvim/lua/null-ls/helpers.lua:115: command: expected string (executable), got eslint

NB some functionality seems to work fine after dismissing this error (e.g. organising imports), but eslint diagnostics don't seem to appear.

The debug stacktrace says eslint couldn't be found—I'm not sure if this is related or just a warning, but our eslint config is inside our package.json for this repo (which is a valid place for it).

Debug log

ESLint config file not found (config may still be valid; see diagnostics for errors)
using local executable /Users/sam/Code/progression/progression-app/node_modules/.bin/eslint
enabling null-ls eslint code actions integration
received LSP request for method initialize
enabling null-ls eslint diagnostics integration
enabling null-ls formatting integration
successfully registered null-ls integrations
attempting to watch root dir/Users/sam/Code/progression/progression-app
git config found; scanning root dir
watching dir /Users/sam/Code/progression/progression-app/app
watching dir /Users/sam/Code/progression/progression-app/bin
watching dir /Users/sam/Code/progression/progression-app/config
watching dir /Users/sam/Code/progression/progression-app/db
watching dir /Users/sam/Code/progression/progression-app/db_stats
watching dir /Users/sam/Code/progression/progression-app/docs
watching dir /Users/sam/Code/progression/progression-app/lib
watching dir /Users/sam/Code/progression/progression-app/public
watching dir /Users/sam/Code/progression/progression-app/test
watching dir /Users/sam/Code/progression/progression-app/vendor
received LSP notification for method initialized
received LSP notification for method textDocument/didOpen
running generators for method NULL_LS_DIAGNOSTICS
null-ls: failed to run generator: ...rs/sam/.vim/plugged/null-ls.nvim/lua/null-ls/helpers.lua:115: command: expected string (executable), got eslint
stack traceback:
        ...rs/sam/.vim/plugged/null-ls.nvim/lua/null-ls/helpers.lua:115: in function 'validate_opts'
        ...rs/sam/.vim/plugged/null-ls.nvim/lua/null-ls/helpers.lua:153: in function <...rs/sam/.vim/plugged/null-ls.nvim/lua/null-ls/helpers.lua:151>
        [C]: in function 'pcall'
        ....vim/plugged/plenary.nvim/lua/plenary/async_lib/util.lua:295: in function 'await'
        ...sam/.vim/plugged/null-ls.nvim/lua/null-ls/generators.lua:25: in function <...sam/.vim/plugged/null-ls.nvim/lua/null-ls/generators.lua:21>
received diagnostics from generators
{}
received LSP request for method textDocument/codeAction
running generators for method NULL_LS_CODE_ACTION
spawning command /Users/sam/Code/progression/progression-app/node_modules/.bin/eslint with args:
{ "-f", "json", "--stdin", "--stdin-filename", "/Users/sam/Code/progression/progression-app/app/packs/src/components/for-rails.tsx" }

Help

Yes, but I don't know how to start. I would need guidance

Implementation help

I'm also slightly confused, as clearly in the debug output the plugin has found the location of eslint as it successfully spawns the command. Could this be because vim.validate expects the command to be globally installed, whereas we don't have eslint installed globally, only in the project node_modules?

If so, seems like we should not be validating that eslint is an executable at that point as the LS manages to find the binary anyway?

samtgarson commented 3 years ago

Config available here! https://github.com/samtgarson/dotfiles/blob/nvim-lsp-ts-utils/dot_config/exact_nvim/lua/lsp/_typescript.lua

jose-elias-alvarez commented 3 years ago

Thanks for the detailed report! Your information led me to realize that a recent refactor wasn't correctly overriding the command with the local executable. 8c3fb52a80eb13bacd5adcd847c2e3add1dc1e00 should take care of it, so could you try updating and let me know if it fixes the issue?

samtgarson commented 3 years ago

That seems to have solved the validation error, thanks! But I'm now getting all sorts of other weirdness...

Something seems to be timing out:

command timed out after 5000 ms
error output: nil
output: nil
received diagnostics from generators
{}
command timed out after 5000 ms
error output: nil
output: nil
received code actions from generators
{}
command timed out after 5000 ms
error output: nil
output: [{"filePath": REDACTED }]
output: nil
Error executing vim.schedule lua callback: ....vim/plugged/plenary.nvim/lua/plenary/async_lib/util.lua:176: Oneshot channel can only send once
received code actions from generators
{}
received LSP request for method textDocument/codeAction
running generators for method NULL_LS_CODE_ACTION
spawning command /Users/sam/Code/progression/progression-app/node_modules/.bin/eslint with args:
{ "-f", "json", "--stdin", "--stdin-filename", "/Users/sam/Code/progression/progression-app/app/packs/src/components/for-rails.tsx" }

I'm able to run that command in a terminal and receive almost instant output.

Very occasionally diagnostics will appear and then disappear for things which I know should fail eslint rules, but in general I'm not getting any feedback from eslint at all 🤔

Should I open a new issue, does this look familiar?

jose-elias-alvarez commented 3 years ago

Sorry for the late response, but yes, if you're still having the error let's open up a new issue.