fix(denols): prevent detecting non-deno TypeScript projects #4207
+18
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Currently, non-Deno TypeScript LSPs (
ts_ls,tsgo,vtsls) have mechanisms to prevent conflicts by not activatingon_dirwhen a Deno project is detected.nvim-lspconfig/lsp/ts_ls.lua
Lines 56 to 73 in e0fae25
However,
denolslacks such a mechanism. As a result, when a non-Deno project is opened withdenolsenabled, both LSPs become attached.Solution
We will add conflict prevention logic to
denols, similar to what non-Deno TypeScript LSPs have.Currently, Deno has a workspace feature, so we will detect the workspace root using
deno.lockin the same way non-Deno TypeScript LSPs do. Ifdeno.lockis not present and onlydeno.json(c)exists, we will handle it with a fallback.Testing
I confirmed that the expected LSP launched with the expected
root_dirin the following situations: