| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Svelte LSP does not attach to regular JS / TS files. To get notified
about changes in these files, it "needs" to send a custom message via
`notify`.
The VS Code extension uses the same workaround[^1] and it has been
discussed to death how to port it to neovim[^2]. Instead of relying on
users finding out about said discussion, it should be included in the
default configuration.
[^1]:
https://github.com/sveltejs/language-tools/blob/2e2c6c3624f2dd21cbda4d8b4b63e0d4df93152e
/packages/svelte-vscode/src/extension.ts#L346
[^2]: https://github.com/sveltejs/language-tools/issues/2008
|
| | |
|
| | |
|
| |
|
|
|
| |
- 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>
|
