feat: allow explicitly fixing for lines_longer_than_80_chars

[alestiago]

Description

There is no option in FormatCommand to explicitly and only solve for the lines_longer_than_80_chars linter rule.

Additional Context

• All available fixes by FormatCommand (there are options to explicitly solve for docComments, functionTypedefs, namedDefaultSeparator, optionalConst, optionalNew and singleCascadeStatements).
• Related issue refactor: introduce "code" option to FormatCommand #1333

[munificent]

I'm not sure what you have in mind here. The formatter's main job is to address that lint as best as it is able. You don't need to use --fix for that: formatting itself changes the line lengths.

[alestiago]

Thanks @munificent for the quick reply. Let me try and rephrase and give a use-case for this. As far as I am concerned, doing dart fix will not only resolve lines longer than 80 chars but also trailing commas and more lint rules. This is requesting to provide a "way" to only solve for a specific lint rule (nothing else, nothing more). In other words, if a given code has a line longer than 80 chars (that can be resolved by the formatter) and is also missing trailing commas, being able to only solve for the lines longer than 80 chars (a single and specific lint rule) and not the missing trailing commas. Is there already an existing and convenient way to tackle this with the dart format only?

P.S. I was originally expecting something as convenient and intuitive as the "code" in dart fix, hence #1333

---

As for the use-case, say you have a Dart template generator, that you give inputs such as the project name. The output of the template generator will be some Dart code based on those inputs. For example, the generated code might include a class with a name based on the project name input. This might make, in some cases, the generated code surpass the 80 chars limit. Now consider the maintenance of the template generator, you would like to check that the template itself is well formatted (makes the maintenance of it much easier since it makes it "look nice to most human readers") but ignore/tolerate those longer lines due to the arbitrarily long input project name.

There are different ways one could resolve the above use-case. A possible solution would be to fix only those lines longer than 80 chars after the generation, and consequently use the --set-exit-if-changed argument to evaluate if there are issues in the template itself that must be resolved besides the 80 chars limit.

[munificent]

In other words, if a given code has a line longer than 80 chars (that can be resolved by the formatter) and is also missing trailing commas, being able to only solve for the lines longer than 80 chars (a single and specific lint rule) and not the missing trailing commas.

Trailing commas aren't the best example here since the formatter will be treating those as whitespace at some point (#1253), but in general, yes, if you just run dart format, then it will fix long lines (and reformat non-long lines as well) but not apply any other lint fixes.

This might make, in some cases, the generated code surpass the 80 chars limit. Now consider the maintenance of the template generator, you would like to check that the template itself is well formatted (makes the maintenance of it much easier since it makes it "look nice to most human readers") but ignore/tolerate those longer lines due to the arbitrarily long input project name.

I'm sorry, I didn't quite follow this. Presumably the template has some concrete placeholder project name with some actual length. If you format the template with that placeholder name, the formatter will do whatever it needs to do to make the code look nice.

Later, when an actual project name is substituted into the template, just format the result of that too. That might wrap some lines differently depending on whether the actual project name is longer or shorter than the placeholder was. Either way, it's fine. Just let the formatter do its thing on any code after you've transformed it, and the result will be as nice as the formatter can make it.

[alestiago]

Thanks again @munificent for the quick reply.

I'm sorry the example use case wasn't clear enough. I can work around with the current dart format arguments.

Ideally, I would like to be explicit on what rule I'm trying to resolve with dart format instead of blindly formatting everything. For example, if you have a code which you already know that it compliant with all lint rules but x and y rules, there is no need to try and solve for all lint rules. In this case only solving for x and y rules will suffice. Similar to how I can explicitly dart fix for certain rules.

I understand than this might be quite complex if the changes made by rules overlap. Feel free to close this issue completely or in favour of #1333 🙌

[munificent]

Ideally, I would like to be explicit on what rule I'm trying to resolve with dart format instead of blindly formatting everything.

Ah, OK. Yes, there are several lints that fire based on whitespace, and it's reasonable to maybe want to fix some but not others.

But, in practice, supporting that would add a lot of complexity to the formatter (especially testing it, which is already quite hard). So even though it's reasonable, I don't think it would be worth the considerable engineering effort. In practice, almost all users just want the formatter to do everything it can do at once.