Introduce: `dart pub add --dry-run --json`
We probably want dart pub add --dry-run --json to output something along the lines of:
$ dart pub add pem --dry-run --json
{
// Text representation of the changes made, this includes multiple lines.
// This may also include warnings of outdated, discontinued, retracted packages, etc.
// This is intended as human readable text that printed to a log, a debug log, or simply ignored and discarded.
"summary": "+ meta 1.7.0\n+ pem 2.0.0\n+ petitparser 4.4.0\nWill change 3 dependencies.\n",
// Changes to be made to files on disk
"changes": [
{
"file": "pubspec.yaml",
"edits": [
// compatible with SourceEdit for analysis_server
{"offset": 100, "length": 0, "replacement": " pem: ^2.0.0\n"},
],
},
],
}
Just like other dart pub commands this will:
- Require
pubspec.yamlandpubspec.lockto be located in CWD (or specified usingdart pub add ... --directory path/to/myapp/), - Modify files in
$PUB_CACHE(notably caching version listings).
Do we know how SourceEdit computes offsets? Is it dart string based (number of utf16 code-units) or byte-offset in the file (or something else entirely?)
I'm closing this because it's unclear if this will be useful for analysis_server. The problem is that even if analysis_server can inject the fix into pubspec.yaml and pubspec.lock, it won't be able to patch .dart_tool/package_config.json, or download package files into $PUB_CACHE. Thus, the UX of this through analysis_server won't be great.
Anyone who needs this feel free to reopen.
Hmm, on second thought if the IDE only updates pubspec.yaml, then the IDE should encourage the user to run dart pub get because modification-times has changed. So maybe this isn't such a bad option, it's just that user will have to save pubspec.yaml and run dart pub get -- but other proposals for quick-fix (https://github.com/dart-lang/sdk/issues/48998) also ends up involving this.
@pq what is the time budget available for generating a quick-fix? How fast would dart pub add --json --dry-run have to be, for this to be an option?
We haven't measured this but it should be very fast. The rub is that until fixes are calculated, we can't communicate (via an affordance in the IDE) that there are fixes available. For example:
RE: analysis server integration, I do wonder if we couldn't cache the result. In that case we might be able to tolerate a slow(er) first response with the promise of subsequent results being instantaneous.
@pq Do we still think this is useful?
Great question. I'm not sure!
/fyi @bwilkerson @srawlins who can chime in on current/planned DAS work and where this might fit in