| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
biome/eslint/ts_ls/tsgo/vtsls #4203
Even though Deno docs says that both deno.json and deno.jsonc files can
be used for its configuration, deno.jsonc was not being considered to
prevent biome/eslint/ts_ls/tsgo/vtsls to run in Deno projects.
|
| | |
|
| |
|
|
|
|
| |
Refactor project root detection logic to properly exclude ts_ls when
deno.json/deno.lock are at the same or higher level than project markers.
Co-authored-by: yzs <yuanzishuai@qq.com>
|
| | |
|
| |
|
|
|
| |
Close https://github.com/neovim/nvim-lspconfig/issues/4129
Since cwd is a necessity for many JavaScript project (see discussions in https://github.com/neovim/nvim-lspconfig/issues/4015), this fix takes an alternative approach to manually exclude Deno projects from biome/eslint/ts_ls/tsgo/vtsls 's `root_dir` detection logic. There is no need to change svelte since it has a different filetype.
|
| |
|
|
|
|
|
| |
Reverts 33e318a3f0e729fb7ee82619a21172712b0ea288 (except for svelte).
fix #4074
close #4076
|
| |
|
|
|
|
|
|
| |
Problem:
Some projects don't have a lockfile.
Solution:
- Fallback to ".git" as a lower-priority root-marker (Nvim 0.11.3+).
- Fallback to CWD.
|
| |
|
|
|
|
|
|
| |
Problem:
`deno.lock` is not recognized as a root marker in JavaScript related
servers.
Solution:
Add `deno.lock` as a root marker.
|
| |
|
|
| |
fix #4023
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PROBLEM:
Monorepos (or "workspaces") in Typescript are more and more popular and
the associated tooling is evolving to improve the developer experience
in such setup. Especially, the `typescript-language-server` and the
`vscode-eslint-language-server` now supports monorepos, **removing the
need to spawn a different server for each package of a workspace**.
Example: with a few packages as the servers need to load every other
package to work (the `typescript-language-server`, even if spawned
multiple times with different `root_dir`, will load in memory other
packages to resolve the types), the amount of memory used grows
exponentially. But in fact, those servers support monorepos: they
support multiple configurations in subpackages and will load the correct
one to process a buffer. The ESLint server even supports loading
multiple ESLint binaries (and therefore versions), while keeping one
instance of the server.
SOLUTION:
Instead of only relying on the configuration files as `root_markers`,
discover the root of the package / monorepo by finding the Lock files
created by node package managers:
* `package-lock.json`: Npm
* `yarn.lock`: Yarn
* `pnpm-lock.yaml`: Pnpm
* `bun.lockb`: Bun
We still need to look at configuration files to enable the conditionnaly
attachment of the LSP for a buffer (for ESLint, we want to attach the
LSP only if there are ESLint configuration files) in case of LSP that
operates on files that are "generic" (like `typescript` or
`javascript`).
To do that, I replace the `root_markers` that were the configuration
files by a `root_dir` function that superseds them. It will both:
* look for a configuration file upward to check if the LSP needs to be attached
* look for the root of the "project" via the lock files to specify the `root_dir` of the LSP
PRIOR EXPERIMENTATIONS:
I've tried to play with the `reuse_client` quite a lot, trying to
understand if we need to spawn a new server or not looking at the
Typescript / ESLint binary that was loaded, but in fact it's way easier
to just have a better `root_dir` that is the true root of the project
for the LSP server: in case of those two servers, the root of the
package / monorepo.
I also tried to use the current directory opened as the `root_dir`, but
it's less powerful on nvim compared to VSCode as we navigate more inside
folders using terminal commands and then open vim.
I think this method also removes the need from a project-local config
(which could be quite useful anyway for ESLint flat config setting which
auto-detection is a bit unreliable / compute heavy) as this should work
normally accross all different setups.
Fixes #3910
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
`vue_ls` made breaking changes to its config in v3.
Solution:
Change the typescript language server for `vue_ls` from `ts_ls` to
`vtsls`.
Add a client handler to communicate between `vue_ls` and `vtsls`.
Remove `typescript.tsdk` option.
Remove documentation for the deprecated takeover mode.
|
| |
|
|
|
|
|
|
|
|
| |
Implement the `editor.action.showReferences` client command, which is
used by the references and implementation code lenses that TypeScript
Language Server provides.
I've mostly based the implementation on the existing code for
`vim.lsp.buf.references()`. The main visible difference is that the
latter includes the item being referenced at the top of the list.
Although, if desired, this could be emulated by manually inserting the
position passed along in the command arguments at the top of the list.
|
| |
|
|
|
|
|
|
|
| |
Problem:
If a server is attached to a non-current buffer by
`vim.lsp.buf_attach_client`, then the Language Server-related
commands may be created in the current (wrong) buffer.
Solution:
Always use the `bufnr` arg provided to `on_attach`.
|
| |
|
|
|
|
| |
The Vue language tooling does not use 'Volar' prominently in its
documentation. The official name for the language server is
'@vue/language-server'.
|
| | |
|
| |
|
|
| |
- Disallow adding new legacy configs.
- Drop the "comment" CI job. It is over-engineered, and adds redundant comments on PRs.
|
| |
|
|
|
| |
Source actions are code actions that apply to the whole file. They are
not exposed via `vim.lsp.buf.code_action()` and must be requested
explicitly.
|
| |
|
|
|
| |
This handler is used when performing certain code actions such as
extracting functions or types. The language server asks the editor to
prompt for a rename for the newly created function or type.
|
| |
|
|
|
| |
- brief should live at the top of each file
- fix indentation for some docs
|
| |
|
|
|
|
|
|
| |
Problem:
Since configs now live in `lsp/`, the docgen needs to be updated.
Solution:
Read the configs from `lsp/`. Parse the `@brief` docstring to get the
docs.
|
|
|
Problem:
Nvim 0.11 has vim.lsp.config, which mostly replaces the legacy
nvim-lspconfig "framework".
Solution:
Migrate all configs to `lsp/*` variants. The old configs in
`lua/lspconfig/` are "frozen".
The new configs include these changes:
- `commands` field became raw calls to
`vim.api.nvim_buf_create_user_command` inside `on_attach`.
- `root_dir` became:
- `root_markers` whenever the file list was simple didn't need to mach `*`
- if the logic was complicated, or needed to match something like
'\*.c', it was defined as a vim.lsp.Config `root_dir` callback.
- `on_config_change` became `before_init`. I don't actually know if this
is the correct approach, but looking around the documentation of
`nvim-lspconfig` a saw that it was defined as the function that gets
called as soon as the config have `root_dir`, and so I thought
`before_init` might be the closest alternative.
- `docs.description` became a luadoc `@brief` docstring.
- `single_file_support = false`?
Co-authored-by: Aliou Diallo <aliou@users.noreply.github.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
