✨ Implement PubspecLineMarkerProvider for pubspec.yaml features

[AlexV525]

Resolves #8511

The PR implements a plugin that provides YAML-related features specifically targeting pubspec.yaml. It includes dependency references currently. Future implementation can be based on this provider.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our [contributor guide](https://github.com/dart-lang/sdk/blob/main/CONTRIBUTING.md for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Dart contributions to our repos should follow the Dart style guide and use dart format.
• Java and Kotlin contributions should strive to follow Java and Kotlin best practices (discussion).

[helin24]

Thanks for looking into this! I'm realizing that for this size feature, we probably need to discuss more the functionality you're adding here.

As a starting point:

1. Can you clarify what this adds? The ability to click on versions and see the package on pub.dev, and also some line markers?
2. Can you add a video or screenshots showing what this looks like?
3. Can you describe edge cases that could arise (e.g. the private pub server that you mentioned in the issue) and how we should handle those?

[AlexV525]

After a good night's sleep, I've identified more areas for improvement. I'll update them today. :) But I can definitely give some preview:

1. Can you clarify what this adds? The ability to click on versions and see the package on pub.dev, and also some line markers?
2. Can you add a video or screenshots showing what this looks like?

EDIT: LineMarkerProvider is a provider from IntelliJ that provides the ability to add markers to a single line.

At first glance, you can see the Dart icon is now available at the head of packages.

When you click on any of it:

A pop-up menu shows, you can check several packages about the package, including the home page, the version page, and the API documentation page.

For git/path dependencies:

For overrode dependencies, "Original Dependency" section is available:

3. Can you describe edge cases that could arise (e.g. the private pub server that you mentioned in the issue) and how we should handle those?

Regarding the private server, I'm planning to open a separate request to add a per-project setting to configure pub host after we stabilize this feature, and it should have a lower priority. Other cases, like mirror sites, must live on pub.dev since it's the only effective source to our ecosystem.

The edge cases about the version constraints will be tested in the unit tests.

[helin24]

Great, thanks for the info, it helps me understand a lot more. We'll discuss this feature and approach next week; I recommend waiting until then to continue work on it. Hopefully we can give you clear guidance after convening!

[AlexV525]

@helin24 How is the internal meeting going? Do we have further ideas about this change?

[helin24]

@AlexV525 sorry about the delay - we have this on the agenda to discuss, but due to a variety of fairly random factors we haven't gotten to it yet! I promise you will hear from us though.

[helin24]

@AlexV525 we finally discussed this; here are our thoughts:

• We will soon be publishing the Dart plugin, and this code should go into the Dart plugin instead. So let's hold off on merging it to the Flutter plugin.
• We want to make sure that the provider doesn't take long - you may have already considered this and avoided network calls, etc.
• We should also consider whether this functionality should be added by the analysis server so that it can also go into VS Code. Any thoughts @bwilkerson @DanTup?

CC @jwren @pq

[bwilkerson]

I haven't had a chance to look at the specific features, but we do already have support for pubspec.yaml (and other YAML files) in the analysis server, so it would definitely be preferable to add this support in the server where possible. Sounds like we need a side-by-side comparison so that we can ensure that we have parity wherever possible.

[DanTup]

We should also consider whether this functionality should be added by the analysis server so that it can also go into VS Code. Any thoughts @bwilkerson @DanTup?

We do already have some of this (opening on pub.dev/github) in the server in LSP's Document Links:

https://github.com/dart-lang/sdk/blob/main/pkg/analyzer_plugin/lib/src/utilities/navigation/document_links.dart

I don't know if there's anything missing compared to what's here, but if so I also agree it'd be best to add it to the server and then reuse that data here (it avoids multiple implementations and keeps them consistent across editors).

[helin24]

Thanks for the info! @AlexV525 for the moment we'll close this PR on this repo. When the Dart plugin is open source, we can add this PR as a first step. Following that, we can improve by integrating the analysis server info. If we have a chance to look investigate the analysis server output (or you want to look into it) then we may be able to use that in the Dart plugin as part of the initial change instead of this PR.

[AlexV525]

Good to know all these details. Thanks

When the Dart plugin is open source, we can add this PR as a first step.

IIRC, isn't the Dart plugin open-source already? https://github.com/JetBrains/intellij-plugins/tree/master/Dart