Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Add cross-language auto-suggest feature for package dependencies #14406

Closed
1 task done
panchi64 opened this issue Jul 13, 2024 · 4 comments
Closed
1 task done

Add cross-language auto-suggest feature for package dependencies #14406

panchi64 opened this issue Jul 13, 2024 · 4 comments
Labels
enhancement [core label] potential extension Functionality that could be implemented as an extension (consider moving to community extensions)

Comments

@panchi64
Copy link

panchi64 commented Jul 13, 2024

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

image image
@panchi64 panchi64 added admin read Pending admin review enhancement [core label] triage Maintainer needs to classify the issue labels Jul 13, 2024
@JosephTLyons JosephTLyons added potential extension Functionality that could be implemented as an extension (consider moving to community extensions) and removed triage Maintainer needs to classify the issue admin read Pending admin review labels Jul 16, 2024
@lemilonkh
Copy link

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

@EvinceMoi
Copy link

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

@kurtbuilds
Copy link
Contributor

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
Copy link

I implemented it for rust:

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

@zed-industries zed-industries locked and limited conversation to collaborators Jan 8, 2025
@notpeter notpeter converted this issue into discussion #22847 Jan 8, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement [core label] potential extension Functionality that could be implemented as an extension (consider moving to community extensions)
Projects
None yet
Development

No branches or pull requests

6 participants