-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow attaching to paths inside archives #1687
Conversation
Thanks for this PR, it will probably help clojure-lsp as well since we do have zipfiles and jar:files buffer types |
Not sure I fully understand. Is the point to trick the root finder into thinking that this file exists on the project path? Then this should be handled in the root finder, instead of special-casing a bunch of lspconfigs. And we definitely would want a few test cases like:
|
I rebased and added tests, plus removed the special casing. The idea is to have the root finder start the search at the zipfile itself, for a buffer with a file inside a zipfile. I have a Yarn v3 project and when I jump to the definition of a dependency, it looks like:
By starting the lookup at |
LGTM |
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This will be breaking primarily for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
The primary (and potentially breaking) change is that `util.root_pattern` traverses once per provided file pattern, while `vim.fs.find` only traverses once. This means that the search will no longer be prioritized by file order, which may break user configurations who unkowingly rely on this behavior. This will also be breaking for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
The primary (and potentially breaking) change is that `util.root_pattern` traverses once per provided file pattern, while `vim.fs.find` only traverses once. This means that the search will no longer be prioritized by file order, which may break user configurations who unkowingly rely on this behavior. This will also be breaking for language servers that rely on code dependencies that is archived but still needs to be read. More context: neovim#1687. Work on neovim#2079.
This change allows attaching to buffers with
zipfile:
ortarfile:
virtual paths.A function
util.strip_archive_subpath(path)
was added to extract the archive path from such a virtual path, androot_dir
fortsserver
is configured to use it by default. This means theroot_dir
search for TypeScript starts at the archive, instead of doing a real traversal starting from the file inside the archive. This is a compromise, because otherwise we'd have to provide a whole bunch of support functionality (currently provided byvim.loop
) to do the necessary checks inside archives.I targeted TypeScript for Yarn PnP support, which keeps project dependencies in zip files instead of
node_modules
. I imagine this may also be useful for other languages, like Java with JARs, but I'm really not familiar with those.An alternative solution I considered was to add behaviour like
strip_archive_subpath
to existing utility functions to accomplish the same, but I'm worried about breaking existing code, and perhaps other language servers need different behaviour.