dart-lang
Add --json output for `pub add`
In https://github.com/Dart-Code/Dart-Code/issues/5802 there is some discussion about having the analysis server use pub add --dry-run to get the version number to add, but then writing it directly into pubspec.yaml (there are a number of reasons why this might be better, in particular supporting unsaved files in the editor, and also allowing the actual pub get to happen in the client, in front of the user where they can see output better).
To do this, it would be better if we could parse structured output from pub add --dry-run instead of regexing human output.
Just a json representation of the same info that is printed today. Perhaps something like:
{
"async": { from: { kind: "transitive", version: "2.13.0" }, to: { kind: "direct", version: "2.13.0" } },
// ... any other packages that would change as a result
}
For the user case above, really we would just care about the to.version field for the package we provided, because the goal is to just write the same version we'd get (if we ran pub add without --dry-run) into the pubspec.yaml in the editor, avoiding issues with unsaved files (and allowing the editor/user to control when pub get is triggered). However, the other information could be useful so since it's already there and printed usually, I think it'd be better to include than make this too narrow.
We could also make it output the updated pubspec.yaml and pubspec.lock to stdout? Would that be easier to consume?
It won't help for the use case above, because the user could have an unsaved pubspec - that's why the exact verison number would be useful, so it could be replaced directly into the pubspec regardless of other changes (of course, if the user has modifications it's not guaranteed pub add --dry-run will produce the same results as if the file was saved, but at least this would handle trivial changes, or changes that don't affect the solve).
Yeah - if we need to handle unsaved pubspec.yaml files, then pub needs to know about those.
Hmm - that seems like a hard problem.
Yeah - if we need to handle unsaved pubspec.yaml files, then pub needs to know about those.
This is not what I understood from @DanTup's message above. The idea is that we get this output, and the tooling can update the pubspec.yaml as they see fit. This would not be a problem pub should be worried about.
Yeah, my plan was to assume that unsaved changes are trivial and would do not affect the results (if we used pub add it would already ignore the unsaved changes, but it would also modify the file and cause conflict notifications in the editor). All we're really trying to do is figure out what the version number is if we had run pub add, so that we can write it into the file ourselves (to avoid the possibility of two versions of the file).
That said, being able to run against the (potentially) unsaved pubspec wouldn't be a bad idea either, so some kind of API to just provide the current contents and get back the new contents also wouldn't be a bad idea. If it wasn't for Workspaces, probably we could've just written the pubspec to a temp folder and used pub add in it.
(although, the more/slower the work we do for this, the more I wonder if doing it quietly in the server is the wrong idea, and we should just force-saved and trigger the real pub add on the client for the user to see 🤔)
Yeah, it feels a bit like we are building the same feature once again inside the server. But I also don't see a better way of doing it, without integrating pub entirely into the analyzer, using its representation of the updated file system.