Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: introduce "code" option to FormatCommand #1333

Open
alestiago opened this issue Nov 28, 2023 · 3 comments
Open

refactor: introduce "code" option to FormatCommand #1333

alestiago opened this issue Nov 28, 2023 · 3 comments

Comments

@alestiago
Copy link

alestiago commented Nov 28, 2023

Description

The FormatCommand should offer a --code argument, as in FixCommand to apply fixes to specific lint rules instead of using --fix-<non-standard-code> (currently documented as used for non-whitespace changes only).

Additional context

The FormatCommand is being consumed by dartdev, a command-line utility for Dart development (part of the Dart SDK).

The package:dartdev exposes a FixCommand that accepts a code argument. This is very useful, since it allows to explicitly resolve fixes for a specific linter rule.

With FixCommand you can explicitly solve for directives_ordering, by doing:

dart fix --apply --code=directives_ordering # Solves for "directives_ordering"

Note: The directives_ordering code is already well documented in Dart Linter Rules.

However, the FormatCommand presents another solution which brings inconsistency to the overall Developer Experience offered by the command-line utility for Dart development.

dart format . --code=avoid_single_cascade_in_expression_statements # Could not find an option named "code"
dart format . --fix-single-cascade-statements  

Note: there is no documented "single-cascade-statements" rule in the Dart Linter Rules, instead there is "avoid_single_cascade_in_expression_statements".

@alestiago alestiago changed the title refactor: deprecate "fix--" in favour of "code" argument refactor: introduce "code" option to FormatCommand Nov 28, 2023
@munificent
Copy link
Member

The --fix support in dart format is pretty old, which mostly explains why its names don't agree with the linter. Instead of updating the names in --fix, I think the better solution that we're working toward (thanks @keertip!) is to make dart fix fast enough for users to use it for all of the things where dart format --fix is currently supported and faster. That will enable us to remove dart format --fix entirely and have one canonical way to apply code fixes: dart fix.

Given that, I think it's unlikely that we'll bother changing the API of FormatCommand, but if it's urgent or important, I'm up for discussing it.

@alestiago
Copy link
Author

Thanks @munificent for the quick reply. I'm happy with the suggested better solution. Is there a way I can track the work towards making dart fix fast enough?

@munificent
Copy link
Member

I believe @keertip is working on this, or at least was intending to at some point. I'm not sure if she has any tracking issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants