Elevate messages from `dart pub get`

We put a lot of work into messages coming out of dart pub get.

We have messages like:

• Current package version have been retracted.
• Newer a.b.c version available.
• Package is discontinued.
• Package is discontinued, replaced by package:foo.
• Summaries of changes.
• Content hash from pubspec.lock doesn’t match content from server (new in 2.19)
• Package version affected by security advisory (coming in the future)

Perhaps we should start a conversation about how we can highlight this information to users. Context: we sometimes discover that users run into issues that were fixed 2 months ago, because they never run dart pub upgrade, even after an SDK upgrade.

Maybe, improving messaging here could help. This is just to open a discussion, maybe we’d want pub to have other output. Or maybe this is better injected through the LSP.

cc @sigurdm, @szakarias

[devoncarew]

In terms of having a place to display richer information, perhaps we could decorate the pubspec.yaml file when the user opens it? We could use synthetic labels after a package dep to display additional information about the package:

dependencies:
  args: ^1.7.0 # on version 1.7.1; version 1.8.0 is available
  collection: ^1.0.0 # on version 1.2.3; version has been retracted!
  path: ^2.0.0 # on version 2.1.0

[DanTup]

One possibility is that dart pub get writes a .dart_tool/pub/dependency-summary.json that exposes these messages for analysis_server/lsp or IDEs to consume.

Having it on disk has some advantages - both the LSP server (which can produce diagnostics/quick-fixes) and the IDE (which may want to surface some of these things in specific ways that are UI/editor-specific and never likely to fall inside LSP) can access it without spawning (duplicate) commands (plus it removes some complexity of actually running commands, providing output to the user if the command fails/hangs, etc.). If we did this, we should ensure there’s a timestamp in it so tell how fresh the data is (since unlike invoking a command directly, it could easily be stale and I’m not sure we want to rely on the file timestamps).

For some things (like security advisories), I feel like the status bar with some coloured indicator could be good - however it’s less simple to invoke a quick-fix from there because it’s not driven by the analysis server. We could probably handle this with a well-known server command that could be invoked if you chose to ignore it though (which lets the server produce the pubspec edits).

Is it worth trying to come up with an example of some JSON for the the kind of information you have for each of these? Perhaps some of them can be generalised (so the IDE/server don’t need to quite know the specifics of every item if many of them will generally be treated the same, just with some different text/identifier).