Both `format` and `fix` may introduce changes that the other will change again

[mdazy]

dart fix --apply may produce changes that will require new formatting (e.g. adding a missing trailing comma before a closing bracket) and dart format --fix may produce changes that will require new fixes (e.g. splitting a long line without inserting the trailing comma):

  // 1. dart fix --apply is initially OK with this long line
  // 2. dart format --fix splits the line but does not insert the trailing comma
  // 3. dart fix --apply adds the trailing comma but leaves the trailing bracket
  // 4. dart format --fix splits the trailing bracket to a separate line
  foo('this is a very very very very very very long string', 'this is another very very very very very very long string');

As a result, it's not possible to use either fix + format or format + fix in a pre-commit hook and ensuring that the resulting code will not require yet more changes before it's stable. If then a CI process attempts to check that the code is lint-free and properly formatted, such a check may fail.

Please see this minimal reproduction.

Dart info

#### General info

- Dart 3.1.3 (stable) (Tue Sep 26 14:25:13 2023 +0000) on "macos_arm64"
- on macos / Version 14.1.1 (Build 23B81)
- locale is en-FR

#### Project info

- sdk constraint: '^3.1.3'
- dependencies: 
- dev_dependencies: lints, test

#### Process info

| Memory |  CPU | Elapsed time | Command line                                                                    |
| -----: | ---: | -----------: | ------------------------------------------------------------------------------- |
|   9 MB | 0.0% |        19:05 | dart devtools --machine --try-ports 10 --allow-embedding                        |
|  25 MB | 0.0% |        19:05 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.76.1 |
|  15 MB | 0.0% |        19:05 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.76.1 |
|  35 MB | 0.4% |        19:05 | flutter_tools.snapshot daemon                                                   |

[lrhn]

Using fix should not produce code that requires formatting.

The issue here, in one direction, is likely that the fix operation is being run on unformatted code, and a fix (insert trailing commas) is decided to not apply because everything is "on one line". It doesn't fit on one line, but the lint doesn't check for that, it assumes input is already formatted. Which is wrong.

The other direction would be that the fix inserts code that doesn't meet formatting requirements. I think that's what we should change.

The formatter has the final say on how to format Dart code.
The fix command should either make sure to format any code it changes using the formatter, or to insert code that definitely doesn't need formatting. The latter is not really a viable strategy, it requires the fix command to understand all the intricate rules of formatting, which can change over time.
So the fix command should format the code that it changes, before writing it back. And it should probably re-analyze that code, to see if new fixes apply, and repeat until done.

If we do that, then you should be able to do dart format first and dart fix afterwards, and still have correctly formatted code.

(Unless we can find a piece of code such that the formatter and fix will somehow go into a loop of "do change - do format - undo change - undo format - repeat". If that's the case, the fix should probably be reconsidered.)

[bwilkerson]

It doesn't fit on one line, but the lint doesn't check for that, it assumes input is already formatted. Which is wrong.

I agree that it's less than ideal, but not assuming that everything is formatted would require the lint to, as you said, "understand all the intricate rules of formatting" in order to know whether the formatter will split the line when it's run, which, as you also noted, isn't viable.

The other direction would be that the fix inserts code that doesn't meet formatting requirements. I think that's what we should change.

Not everyone uses the formatter to format their code, so running the formatter over fixed code wouldn't always be the right option.

That said, one of the things I've been advocating for is to add a way for users to indicate that they do use the formatter to format their code. dart fix could then use that signal to know to run the formatter as part of fixing as you suggested. We could also make other code-changing operations, such as refactorings, do the same. I think we could improve the UX of our tooling if we had that explicit signal.

The other thing I'll point out is that the proposed changes to the formatter would make this particular lint obsolete, and it's the only one that I'm aware of that has this kind of interaction with the formatter. So even if we can't automatically run the formatter as part of dart fix there's still hope that we can solve this problem. (Unfortunately it might not be soon, though.)

[lrhn]

Yep, I think the fix tools should assume that input is formatted, and make sure its own changes are formatted before being written back.

Then dart format & dart fix would be the recommended order.
(Really, "dart format all the time", like on save, is what we would be assuming.)