Add cross-language auto-suggest feature for package dependencies

[panchi64]

Check for existing issues

• Completed

Describe the feature

I would love if someone implemented an auto-suggest feature for package dependencies across multiple programming languages. This feature would significantly improve the developer experience when working with various projects, particularly in managing dependencies in files like Cargo.toml for Rust, package.json for JavaScript/Node.js, requirements.txt for Python, and similar dependency management files in other languages

Note

It also doesn't have to be limited to rust crates, python dependencies, or nodejs packages either. It would be nice to have different languages supported as well.

Current behavior:

• Users must manually type or look up crate names and versions.
• No suggestions are provided while typing crate names or versions.

Proposed feature:

Package Version Auto-suggest:

• When a user types a package version, show a list of available versions.
• The list should be sorted with the most recent versions at the top.
  • Example: When typing the version for a package, show options like "2.1.0", "2.0.9", "2.0.8", etc.

Package Name Auto-suggest:

• When a user starts typing a package name, show a dropdown list of matching packages.
• Include a brief description of each package in the suggestions.
  • Example: In a JavaScript project, typing "re" might suggest "react" with a brief description.

Benefits:

• Faster and simpler dependency management
• Reduced errors from typos or incorrect versions
• Easy discovery of available crates and their purposes
• Quick access to the latest versions of crates

Quality of Life Improvements:

• Streamlined workflow for adding and updating dependencies
• Reduced context-switching between the editor and crates.io for version lookups
• Improved discoverability of crates, especially for newcomers to the Rust ecosystem

If this is a feature that should be turned into an extension instead, please let me know so that I can start working on it separately.

If applicable, add mockups / screenshots to help present your vision of the feature

[lemilonkh]

Would love to see this! Specifically for Rust and NodeJS. Maybe one last thing before I can fully move over from NeoVim 😊 ✨

[EvinceMoi]

Just like the dependi extension on vscode, very useful, would like to see that coming

[kurtbuilds]

Been doing some thinking and proof of concept coding on this because I miss the autocompletion from IntelliJ in Zed.

The current solution is to have multiple LSPs running, however, the suggestions from them tend to conflict with each other. Right now taplo gives terrible results for package versions (#15261), and I think the only way to configure taplo to disable that is to disable taplo for all Cargo.toml files (which means turning off completion for the other fields in Cargo.toml). It's also redundant to have multiple processes create a DOM for the toml (or json doc) you're looking at.

At the same time, we're unlikely to have the LSP for the config file format have functionality for each ecosystem. taplo rejected my suggestion and pull request for explicit Cargo.toml support (tamasfe/taplo#689 and tamasfe/taplo#690). This arguably makes sense - taplo shouldn't go down that road, as it would mean supporting pyproject.toml and any other language that wants package completion and wants support.

Instead, I think it might make sense to allow delegation between LSPs. Rather than have LSPs proxy (how would the LSP know if user wants to run a LSP with specific settings?), the LSP should respond that it suggests package completion. And then the user runs LSPs (which could be rolled into vtsls and rust-analyzer) to execute that command.

Overview

1. taplo (for toml) and vtsls (for json) use some kind of extension within the schema (taplo already supports x-taplo and previously had a plugins key on that object) to understand when to respond to LSP request textDocument/completion with a command instead of a completion. In that case, it would respond with a completionList with itemDefaults.data (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionList) set to a Command object. Command would tell the editor (Zed) that it should perform package, version, or feature completion. It would come back in this schema because LSP doesn't have an explicitly supported schema for returning delegation / a command back from auto-completion.
2. Zed handles the response. It would have to special case receiving a Command back in completionList.itemDefaults.data and know to execute that as a command for the LSPs.
3. Zed sends a dollar request to the correct LSP (a new cargo-toml lsp, or eventually rust-analyzer if it merges back in) requesting completion for the given package, feature, or version.
4. The response to the dollar request would be a CompletionResponse.
5. Zed handles the completion response.

It's very doable, but it requires a few different players (taplo, Zed, optionally rust-analyzer too) to implement some extensions to LSP - so I'm not sure how feasible this approach is.

The alternative is to have a custom LSP cargo-toml-lsp and package-json-lsp - either implemented as forks of taplo and vtsls respectively and have configuration on taplo to ignore Cargo.toml files, so that only cargo-toml-lsp handles it. This is the most straight forward approach, but it means that the fork can get out of sync, and the fork might not always pull in features and bugfixes implemented by taplo/vtsls.

Right now, my needs are mostly met by running my custom fork of taplo which contains Cargo.toml support - I don't live in js ecosystem enough to really need it for package.json - but I'd contribute to the solution if we can get consensus on the right path forward.

[frederik-uni]

I implemented it for rust:

https://github.com/frederik-uni/zed-cargotom