Implement `dart fix`

[tddawson]

I love DartPad, especially as an instructional tool to get people playing with Flutter/Dart without having to install anything.

While ultimately informative, I find the frequent info-level issues, underlines, and notifications confuse first-timers. For example, I understand how it can be good practice to get people in the habit of using 'const' properly, but when someone's just playing around it's scary and confusing to see things like:

"Prefer const literals as parameters of constructors on @immutable classes."

These can be especially annoying if you start development with placeholder widgets, add const to appease the linter, then see an actual issue when you change the widget to something non-constant.

I'd love to be able to have greater control over whether these show up, or generally more clarity for new users about what they need to be concerned about.

[parlough]

I know this isn't a perfect solution, but you can ignore all lints by adding the following to the top of your file:

// ignore_for_file: type=lint

If you're sharing example code through an embedded DartPads you could even include this in your test.dart file and it will apply to the main.dart.

[domesticmouse]

Is there a lints that would be useful to take out?

With that said prefer_const_literals_to_create_immutables has a fix, so maybe the better fix is providing dart fix as an analog to dart format in the DartPad UI...

[parlough]

I love the idea of exposing a full dart fix :)

[tddawson]

Thanks for the responses!

Helpful to know about ignoring lints per-file.

I understand the value of lints, so I don't know that removing specific ones is necessary. I love the idea of a dart fix within dart pad! Would still have the educational benefits, but without requiring first-timers to read documentation that would likely be over their heads to fix the scary squiggly lines.

[domesticmouse]

@devoncarew is dart fix style functionality available via analysis_server? I see something called BulkFixes in analysis_server_lib but I don't see edit.bulkFixes documented in the protocol. Am I missing something?

[devoncarew]

Ah, perhaps portions of that API are marked as experimental / hidden? I'll take a look. It may be that it wasn't intended to be something users leveraged, but more a communications mechanism between the analysis server and the dart fix cli tool.

[devoncarew]

That (generated) protocol doc may leave out 'experimental' portions of the API. I do see that api in the spec file, marked experimental="true".

package:analysis_server_lib does generate all the api, and uses @deprecated and @experimental annotations for those portions of the api.

You could try out using the API as an experiment, but you'd want to have a conversation with the analyzer team before actually relying on that functionality in dartpad (the dart fix cli tool is I believe the only place where that api is used today).

[domesticmouse]

You could try out using the API as an experiment, but you'd want to have a conversation with the analyzer team before actually relying on that functionality in dartpad (the dart fix cli tool is I believe the only place where that api is used today).

Who is on the analyzer team?

[devoncarew]

@srawlins and @bwilkerson are good POCs there.