Repository navigation
Add "Fix All in Workspace" commands to apply fixes across the whole workspace instead of only current file #5022
Description
Seems we don't have an issue tracking this. We should support running "dart fix" for your workspace in the IDE, rather than telling users to run from the command line.
Activity
DanTup commentedon Mar 7, 2024
Here's how this currently looks. There are two commands, one that just applies fixes immediately, and another that previews them.
Unfortunately there are some things I don't like when previewing:
Related VS Code issue: Workspace edits with metadata do not show labels that docs say are rendered prominently microsoft/vscode#176984
I don't think either of these should prevent us doing this, but it's not as good an experience as it could be.
fix.all.mp4
DanTup commentedon Mar 12, 2024
With changes to the prompt:
fixes.prompt.mp4
bwilkerson commentedon Mar 12, 2024
Should the prompt indicate how to compute and apply fixes?
DanTup commentedon Mar 12, 2024
Do you mean should it indicate you should tick them and click Apply? Perhaps it should. I'd really like them ticked by default (I thought we could, but I can't figure out how now.. I will do more digging and file an issue in VS Code/LSP if appropriate).
Suggestions for the text are welcome (the current texts are constants at the top of the class in https://dart-review.googlesource.com/c/sdk/+/357120/2/pkg/analysis_server/lib/src/services/user_prompts/dart_fix_prompt_manager.dart)
bwilkerson commentedon Mar 12, 2024
I'm mostly thinking about discoverability.
I was assuming that the fixes wouldn't be opened automatically, but that users would need to do something to get them computed or at least see them. Whether that's running a command, opening a preview tab, or something else, I know that I wouldn't immediately know how to get automated fixes for all of the diagnostics.
DanTup commentedon Mar 12, 2024
Do you mean, should we indicate in the prompt (shown in the video above) how to re-run the command without seeing the prompt (because the prompt is only shown on certain triggers)?
The prompt itself has buttons to run the commands so I think it's clear there. Perhaps it's not clear how you access this functionality without the prompt, but probably that's the same issue for all of the other commands. The way you'd currently find it is from filtering the command palette with to things containing "fix all".
We could add it to the editor context menu, though that might be slightly odd because the action isn't editor-specific (and we have a lot of other commands we don't add there but probably have similar discoverability concerns).
[analysis_server] Add the ability for the "dart fix" prompt to use in…
bwilkerson commentedon Mar 12, 2024
You're right, it does. I completely missed seeing them. The buttons alleviate all of my concerns.
I agree, the editor's context menu doesn't make much sense. If we could add it to the Explorer view that would make sense, but I seem to remember that we can't.
DanTup commentedon Mar 12, 2024
If you mean here, I think we can add icons there.. but since we have a lot of workspace-wide commands I think trying to decide which ones are important enough to include there would be quite subjective.
In general I think we should try to train users to use the palette and get used to searching to try to find things because that feels how VS Code is designed. Typing "dart fix" into the command palette will show up the new commands for example. A large amount of functionality I use is found that way (I think I may have seen they're also exploring having the filter not require exact matches, to try and be more like a search than a filter). It's definitely not everyone's preference, but unless VS Code gets something more like a toolbar (or the ability to contribute a top level menu!) I think our options are quite limited.
bwilkerson commentedon Mar 12, 2024
Sorry, I wasn't very clear. What I was thinking about was making it possible for a user to select a directory (possibly a package) and run 'dart fix' in the selected directory. It would be nice if users could control which subset of the whole workspace will be fixed. Certainly not necessary, though.
DanTup commentedon Mar 13, 2024
Oh, I see! I think we might be able to support that.. we could have a command on the explorer context menu for "(Preview) Fix All in Folder" that triggered a similar command to this one that passes the folder(s) to the server. We'd ofc need to update the
BulkFixProcessorto support it, but since it already does "everything" and "this specific file" it seems like that shouldn't be difficult.We could restrict to a specific package, but except possibly for nested packages, folder is probably more flexible and can achieve the same.
I've opened #5034 to track this - it'd first need some investigation to exactly what we can contribute to explorer (but since we already have things like "Open in Android Studio" on the "android" folder, I'm sure we must be able to do this).
[-]Support "dart fix" directly in the IDE (applied over overlays, with refactor preview)[/-][+]Add "Fix All in Workspace" commands to apply fixes across the whole workspace instead of only current file[/+]DanTup commentedon May 9, 2024
I'm splitting this because there are two parts to this that might ship separately.
This issue is for the "Fix All in Workspace" commands, which are invoked from the palette. I had mistakenly believed I'd left those commands always enabled (when supported), but now I see they are gated on the pre-release flag for the SDK:
https://github.com/Dart-Code/Dart-Code/blob/995d9770367208290c282657161afb1ca40aff7e/package.json#L1120=L1127
The other part is updating the prompt you see when opening a project that has fixes. That is also gated on the pre-release flag.
I think the UX concerns are really for the latter, which guides users to use "Preview", whereas the commands (which users are more explicitly choosing to use, without a prompt) aren't too bad (if the user is familiar with the commands, they'd be more likely to know they can run the Apply one to skip the preview/checking boxes).
So, I'm splitting the prompt into #5100 and we can enable that when the UX is better in VS Code (or we decide not to wait and just take it as-is).
For the commands, I plan to remove the pre-release requirement in the next Dart-Code release (around end/start of month) and include that in the Dart-Code release notes then.
(fyi @jwren @bwilkerson @anderdobo in case you have any other opinions/preferences)
bwilkerson commentedon May 9, 2024
That sounds reasonable to me.
jwren commentedon May 9, 2024
Yes, sounds reasonable.