Update to call new `dart` tool

[mit-mit]

Several CLI commands are being deprecated from the Dart SDK (e.g. dartfmt, dartanalyze) in favor of a single dart comment; see: dart-lang/sdk#46100

It would be great to update this plugin to use dart instead.

[mit-mit]

cc @natebosch

[natebosch]

cc @sigmundch @cbracken

Have we made any decisions about how backwards compatible we want to be with older Dart SDKs?

@mit-mit - do we have policy about backwards compatibility with our intelliJ or VSCode plugins?

[mit-mit]

We don't really have a policy. But given these have been here for several stable releases (since Oct 2020), I'd be fint assuming them by now.

[cbracken]

I admit I generally lean pretty heavily towards backwards-compatibility -- I mean, at some point package:coverage supported about 9 different variants of the VM service protocol -- but I suspect we're good to move forwards with this. A few options:

1. We could use some fallback scheme where we use the new command for new SDKs and the old command for older ones. A few possible options there: check the version and if >= 2.10 (I think?) issue the new command, otherwise the old one, or check for the presence of the old command on the path and if it's there, use it, if not, use the new one.
2. Easier and more readable: we could tag the last version before we move to the new dart commands so that people who need to work with old SDKs can pin themselves to that tag.
3. Easiest: we could just move to the new commands and let people pin to a SHA if they need to.

Honestly, I'm fine with any of those options but lean towards 3. I suspect the main users who need some form of backwards-compatibility are corporate/enterprise users who often lag behind public releases by months/years. Worst-case scenario, people start filing bugs and we implement option 1 then, if it turns out to be a problem.

@mit-mit is the plan to eliminate the old commands altogether after some transition period? If so, do you have a timeline?

EDIT: ah, it's mostly documented on dart-lang/sdk#46100 with some TBD.

[mit-mit]

Yes, 2.10 is the minimum version.

is the plan to eliminate the old commands altogether after some transition period?

Yes, but it will not happen all at once, see dart-lang/sdk#46100

[natebosch]

Blocked for dartfmt case by https://github.com/dart-lang/sdk/issues/46379

[cbracken]

The exit code issue (which is now dart-lang/dart_style#1035) is now fixed.

[natebosch]

We need to decide whether we make a hard flip to the new API and require users to pin older versions of the plugin if they are on an older SDK where it doesn't work, or whether we want to try to parse the dart version and pick which executable to run based on that.

Any thoughts on that @cbracken @sigmundch ?

[sigmundch]

My inclination here is to detect the version. Especially given that I expect many external developers to be a couple stable versions behind the latest. As a result, they would miss on any other fix we may add in the plugin later in time until they are ready to upgrade on the Dart side.

To get a better picture:

• how hard is it for folks to pin an older version of the plugin?
• how would they know that they need to do so? Would we anyways need to detect the version to provide a reasonable error message and guide them to pin the old version?

[natebosch]

• how hard is it for folks to pin an older version of the plugin?

It depends on the method they used to install, but it's usually a short config. The tricky part is your next question.

• how would they know that they need to do so? Would we anyways need to detect the version to provide a reasonable error message and guide them to pin the old version?

This could end up being about the same complexity as detecting the version.

My inclination here is to detect the version.

Yeah I think I'm leaning that way too. I'll see what it might take to implement it.

[natebosch]

I added SDK version scraping in #125