Skip to content

Conversation

krukroman
Copy link

This pr is intended to fix issue #4015

Problem:

ts_ls, vtsls, tsgo LSP do not start for standalone files
eslint/biome LSP do not start when there is config file but lock file is absent in workspace directory

Solution:

ts_ls, vtsls, tsgo: Remove redundant truthy check when calling on_dir(project_root). If project_root is provided, it will be used as root_dir; otherwise, root_dir will be nil, allowing the LSP to start for standalone files.

eslint/biome: added check for config root directory when project root directory not found

Please, consider that i am a beginner, so I will be grateful for any suggestions for improvements.

problem:

ts_ls, vtsls, tsgo LSP do not start for standalone files
eslint/biome LSP do not start when there is config file
but lock file is absent in workspace directory

solution:

ts_ls, vtsls, tsgo: Remove redundant truthy check when calling `on_dir(project_root)`.
If `project_root` is provided, it will be used as `root_dir`; otherwise,
`root_dir` will be `nil`, allowing the LSP to start for standalone files.

eslint/biome: added check for config root directory when project root
directory not found
Comment on lines +89 to +90
-- If project root not found `project_root` will be nil and on_dir function will be called with nil value
-- to allow LSP to start for standalone TS/JS files.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be less verbose. Same for other cases where applicable.

Suggested change
-- If project root not found `project_root` will be nil and on_dir function will be called with nil value
-- to allow LSP to start for standalone TS/JS files.
-- If `project_root=nil`, we still want on_dir() because this server supports "standalone" mode (workspace_required=false).

@justinmk
Copy link
Member

If lsp/eslint.lua and lsp/biome.lua have chosen workspace_required=true then we don't need to workaround that. I suggest dropping those changes for now. Looks complicated. Should be a separate PR if at all.

@krukroman
Copy link
Author

@justinmk , I’ve decided to close this PR, as it only addresses the symptoms of the larger issue that PR #3955 attempted to resolve, but encountered edge cases. At this point, fixing this problem is beyond my current experience, since I believe it is primarily a design issue that requires careful discussion and consideration.

@krukroman krukroman closed this Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants