js/ts language servers (eslint/biome/svelte/ts_ls/vtsls/tsgo) attach to files that are only in workspace directory (ex. directory contains lock file)

[krukroman]

Description

Commit 8ad2d8d introduced changes that restrict mentioned language servers from attaching to files outside the workspace directory. While this behavior makes sense for some servers, it creates inconveniences for JavaScript/TypeScript development.

Problem:

• General JS/TS files: Developers often edit standalone JS/TS files not bound to any workspace or project. The current restriction prevents language servers from attaching to these files, reducing functionality (e.g., linting, autocompletion, and diagnostics).
• ESLint/Biome: These servers do not support single files and should only attach when configuration files (e.g., .eslintrc, biome.json) are present in the directory, even if the directory is not a formal workspace.
• Svelte: Unlike JS/TS, the Svelte language server should likely only attach to files within a Svelte project, as standalone Svelte files are rare and less practical.

Expected Behavior:

• JS/TS Language Servers: Should attach to any JS/TS file, regardless of workspace context, to support standalone file editing.
• ESLint/Biome: Should attach to files when configuration files are present in the directory, even if it’s not a workspace.
• Svelte Language Server: Should only attach to files within a Svelte project.

Current Behavior:

• All mentioned servers are restricted from attaching to files outside the workspace directory,

Possible solutions

example of current eslint config

  root_dir = function(bufnr, on_dir)
    -- The project root is where the LSP can be started from
    -- As stated in the documentation above, this LSP supports monorepos and simple projects.
    -- We select then from the project root, which is identified by the presence of a package
    -- manager lock file.
    local project_root_markers = { 'package-lock.json', 'yarn.lock', 'pnpm-lock.yaml', 'bun.lockb', 'bun.lock' }
    local project_root = vim.fs.root(bufnr, project_root_markers)
    if not project_root then
      return nil
    end

    -- We know that the buffer is using ESLint if it has a config file
    -- in its directory tree.
    --
    -- Eslint used to support package.json files as config files, but it doesn't anymore.
    -- We keep this for backward compatibility.
    local filename = vim.api.nvim_buf_get_name(bufnr)
    local eslint_config_files_with_package_json =
      util.insert_package_json(eslint_config_files, 'eslintConfig', filename)
    local is_buffer_using_eslint = vim.fs.find(eslint_config_files_with_package_json, {
      path = filename,
      type = 'file',
      limit = 1,
      upward = true,
      stop = vim.fs.dirname(project_root),
    })[1]
    if not is_buffer_using_eslint then
      return nil
    end

    on_dir(project_root)
  end,

For eslint/biome servers, the root_dir function should:

• Return if neither a root project marker nor a config file is found.
• Call on_dir(config_file_directory) if only a config file is found (and no root project marker exists).

For ts_ls/tsgo/vtsls, the root_dir function should call on_dir(nil) if there is no project_root to allow these language servers to attach to standalone files, as suggested here by @justinmk.

Previous description

Summary

ts_ls server don't attach to javascript or typescript files when there are no root marker files in directory (ex. package-lock.json)

Steps to reproduce

1. create minimal neovim config file.

Minimal init.lua

vim.o.clipboard = 'unnamedplus'
vim.o.softtabstop = 2
vim.o.shiftwidth = 2
vim.o.expandtab = true


-- Bootstrap lazy.nvim
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  local lazyrepo = "https://github.com/folke/lazy.nvim.git"
  local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
  if vim.v.shell_error ~= 0 then
    vim.api.nvim_echo({
      { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
      { out, "WarningMsg" },
      { "\nPress any key to exit..." },
    }, true, {})
    vim.fn.getchar()
    os.exit(1)
  end
end
vim.opt.rtp:prepend(lazypath)

-- Make sure to setup `mapleader` and `maplocalleader` before
-- loading lazy.nvim so that mappings are correct.
-- This is also a good place to setup other settings (vim.opt)
vim.g.mapleader = " "
vim.g.maplocalleader = " "

-- Setup lazy.nvim
require("lazy").setup({
  spec = {
    "neovim/nvim-lspconfig",
    config = function()
      vim.lsp.enable("ts_ls")
    end,
  },
  -- Configure any other settings here. See the documentation for more details.
  -- colorscheme that will be used when installing plugins.
  install = { colorscheme = { "habamax" } },
  -- automatically check for plugin updates
  checker = { enabled = true },
})

2. install localy ts_ls server npm install -g typescript typescript-language-server.
3. run neovim with minimal config nvim -u /path/to/minimal_init.lua.
4. start editing index.js file :e index.js<CR>.
5. open lsp info :LspInfo<CR>. ts_ls is not an active lsp.
6. start editing index.ts file :e index.js<CR>
7. open lsp info :LspInfo<CR>. ts_ls is not an active lsp.
8. run npm init -y.
9. repeat steps from 4 to 7.
10. create package-lock.json file.
11. repeat steps from 4 to 7. now ts_ls attached to both index.js and index.ts files

Expected behavior

ts_ls server should always be attached to any javascript or typescript files regardless where these files are located

Current behavior

ts_ls server don't attach to javascript or typescript files when there are no root marker files in directory (ex. package-lock.json)

LspInfo

index.js LspInfo

- LSP log level : WARN
- Log path: /home/user/.local/state/nvim/lsp.log
- Log size: 0 KB

vim.lsp: Active Clients ~
- No active clients

vim.lsp: Enabled Configurations ~
- ts_ls:
  - cmd: { "typescript-language-server", "--stdio" }
  - commands: {
      ["editor.action.showReferences"] = <function 1>
    }
  - filetypes: javascript, javascriptreact, javascript.jsx, typescript, typescriptreact, typescript.tsx
  - handlers: {
      ["_typescript.rename"] = <function 1>
    }
  - init_options: {
      hostInfo = "neovim"
    }
  - on_attach: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:110>
  - root_dir: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:56>


vim.lsp: File Watcher ~
- file watching "(workspace/didChangeWatchedFiles)" disabled on all clients

vim.lsp: Position Encodings ~
- No active clients

index.ts LspInfo

- LSP log level : WARN
- Log path: /home/user/.local/state/nvim/lsp.log
- Log size: 0 KB

vim.lsp: Active Clients ~
- No active clients

vim.lsp: Enabled Configurations ~
- ts_ls:
  - cmd: { "typescript-language-server", "--stdio" }
  - commands: {
      ["editor.action.showReferences"] = <function 1>
    }
  - filetypes: javascript, javascriptreact, javascript.jsx, typescript, typescriptreact, typescript.tsx
  - handlers: {
      ["_typescript.rename"] = <function 1>
    }
  - init_options: {
      hostInfo = "neovim"
    }
  - on_attach: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:110>
  - root_dir: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:56>


vim.lsp: File Watcher ~
- file watching "(workspace/didChangeWatchedFiles)" disabled on all clients

vim.lsp: Position Encodings ~
- No active clients

index.js LspInfo with package-lock.json file in directory

- LSP log level : WARN
- Log path: /home/user/.local/state/nvim/lsp.log
- Log size: 0 KB

vim.lsp: Active Clients ~
- ts_ls (id: 1)
  - Version: ? (no serverInfo.version response)
  - Root directory: /tmp/nvim
  - Command: { "typescript-language-server", "--stdio" }
  - Settings: {}
  - Attached buffers: 1

vim.lsp: Enabled Configurations ~
- ts_ls:
  - cmd: { "typescript-language-server", "--stdio" }
  - commands: {
      ["editor.action.showReferences"] = <function 1>
    }
  - filetypes: javascript, javascriptreact, javascript.jsx, typescript, typescriptreact, typescript.tsx
  - handlers: {
      ["_typescript.rename"] = <function 1>
    }
  - init_options: {
      hostInfo = "neovim"
    }
  - on_attach: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:110>
  - root_dir: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:56>


vim.lsp: File Watcher ~
- file watching "(workspace/didChangeWatchedFiles)" disabled on all clients

vim.lsp: Position Encodings ~
- No buffers contain mixed position encodings

index.ts LspInfo with package-lock.json file in directory

- LSP log level : WARN
- Log path: /home/user/.local/state/nvim/lsp.log
- Log size: 0 KB

vim.lsp: Active Clients ~
- ts_ls (id: 1)
  - Version: ? (no serverInfo.version response)
  - Root directory: /tmp/nvim
  - Command: { "typescript-language-server", "--stdio" }
  - Settings: {}
  - Attached buffers: 1, 4

vim.lsp: Enabled Configurations ~
- ts_ls:
  - cmd: { "typescript-language-server", "--stdio" }
  - commands: {
      ["editor.action.showReferences"] = <function 1>
    }
  - filetypes: javascript, javascriptreact, javascript.jsx, typescript, typescriptreact, typescript.tsx
  - handlers: {
      ["_typescript.rename"] = <function 1>
    }
  - init_options: {
      hostInfo = "neovim"
    }
  - on_attach: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:110>
  - root_dir: <function @/home/user/.local/share/nvim/lazy/nvim-lspconfig/lsp/ts_ls.lua:56>


vim.lsp: File Watcher ~
- file watching "(workspace/didChangeWatchedFiles)" disabled on all clients

vim.lsp: Position Encodings ~
- No buffers contain mixed position encodings

Investigation

By using git bisect I found that this Commit 8ad2d8d introduced changes that broke server ability to attach to any javascript or typescript files outside of root directory which contains root marker files (ex. package-lock.json)

[justinmk]

this Commit 8ad2d8d introduced changes that broke server ability to attach to any javascript or typescript files outside of root directory

lsp/eslint.lua and lsp/biome.lua specify workspace_required=true, but not the others, so yes I would expect ts_ls and others to not require a workspace.

I think the way to fix this would be to call on_dir(nil) instead of return nil. I'm not sure if that was intentional @fuegoio

[pratyushmittal]

+1, I am facing the same issue with biome. I am using biome on a static website which doesn't use any lock files. The root directory only contains biome.json without any lock files or node packages.

[krukroman]

Hello, @justinmk

I think the way to fix this would be to call on_dir(nil) instead of return nil.

Can confirm on ts_ls config that your solution is working as expected. ts_ls attaches to javascript/typescript files outside of workspace directory.

root_dir function example

...rest config
          root_dir = function(bufnr, on_dir)
            -- The project root is where the LSP can be started from
            -- As stated in the documentation above, this LSP supports monorepos and simple projects.
            -- We select then from the project root, which is identified by the presence of a package
            -- manager lock file.
            local project_root_markers = {
              'package-lock.json',
              'yarn.lock',
              'pnpm-lock.yaml',
              'bun.lockb',
              'bun.lock',
            }
            local project_root = vim.fs.root(bufnr, project_root_markers)

            local dir_root = project_root and project_root or nil
            on_dir(dir_root)
          end,
...rest config

[justinmk]

pr welcome

[krukroman]

pr welcome

@justinmk pr #4022. Could you please review it when you will have spare time? Thank you.

[hanool]

Similar issue here.
My project uses Git submodules to include sub-projects. However, the vtsls server will treats each sub-project's subdirectory as its root directory.
The change introduced in commit 8ad2d8d seems beneficial for users working with monorepos, but unfortunately, it breaks functionality in my setup.
For now I have to delete lock-files in submodules, and check manually for each commit when I make changes on submodules...
And this change is not marked as breaking change, some project like mine will just not work after update with no warnings.

[krukroman]

Hello @hanool !

Could you please in your package manager switch nvim-lspconfig to commit 782dda9 and check again if vtsls treats your submodules subdirectories as root dirs?

[krukroman]

@justinmk After attempting to fix this issue, I realized that adding workarounds to this implementations of configs, introduced in PR #3955, will only increase complexity and maintainability. Also I tested some behavior of configs on commit 782dda9 before changes, and found that PR only partially achieved its goal. Solutions, that was merged do not prevent LSPs from spawning multiple instances of clients if projects don't follow monorepo structure.

Example project structure every dir is root dir

- project_dir
   - frontend_dir
       - ...files and dirs
       - package-lock.json
       - eslint.config.js
    - backend_dir
        - ...files and dirs
        - package-lock.json
        - eslint.config.js
    - ...files
    - package-lock.json
    - eslint.config.js

Consider the folder structure listed above. If the current working directory is project_dir, the LSP will spawn separate clients for each lockfile and ESLint config, because every directory is treated as a project root due to the presence of root marker files (e.g., opening all three eslint.config.js files results in three ts_ls and three ESLint clients running).

To address this issue properly, we need to agree on:

• The standard criteria for identifying the root folder in TS/JS projects, accounting for all possible edge cases;
• How to search for and apply these criteria;
• How to handle edge cases without introducing excessive complexity;

Alternatively, we could opt for the simplest implementation, as it was before PR #3955, and let users to customize the behavior via vim.lsp.config(server_name, config).

What do you think about this?

[hanool]

@krukroman Checked with commit 782dda9 (the commit before th PR #3955), and vtsls treats the parent dir as root dir.

My current environment.

• local dir of repo = ~/dev/foo
• submodule in the repo = ~/dev/foo/bar

main branch, with yarn.lock file existing in submodule, LspInfo shows,

- vtsls (id: 3)
  - Version: 0.2.9
  - Root directory: ~/dev/foo/bar

main branch, with no yarn.lock(or any lock files) in submodule

- vtsls (id: 2)
  - Version: 0.2.9
  - Root directory: ~/dev/foo

commit 782dda9, with yarn.lock file existing in submodule

- vtsls (id: 2)
  - Version: 0.2.9
  - Root directory: ~/dev/foo

[justinmk]

To address this issue properly, we need to agree on:

• The standard criteria for identifying the root folder in TS/JS projects, accounting for all possible edge cases;

There is no such thing, apparently. How does vscode do it?

Alternatively, we could opt for the simplest implementation, as it was before PR #3955, and let users to customize the behavior via vim.lsp.config(server_name, config).

Well, AFAIR it was not obvious how users could support monorepos before that case.

Or maybe the story changed since Nvim 0.11.3 gained the ability to control "equal priority" root markers (neovim/neovim#34276).

My suggestion in general is that the configs handle the common case while making it easy to opt-in to a custom case. The rubric is like this:

• if monorepos are complex to handle, configs should favor that while letting users easily override (which is already possible via vim.lsp.config('foo', { root_markers=...}), it's designed to "merge" with the default config...)
• if monorepos are easy for users to handle, but the "common cases" are hard to handle, then the configs should favor the non-monorepo case