use the latest formatter on PRESUBMIT

[sigmundch]

See https://codereview.chromium.org/2975253002/ for a discussion on this.

Several people believe we should be using the very latest dartfmt in the repo, while I believe we should be using whatever version the PRESUBMIT is using so we don't get presubmit warnings.

Could the PRESUBMIT be linked to use the latest dartfmt instead of the old version under tools/?

And a partially related question: whenever a new dartfmt is rolled, how do we keep the repo up to speed?

/cc @jacob314

[zanderso]

A few things:

• Flutter and Fuchsia use dartfmt from recent dev SDKs. What does google3 use? What version is pulled into tools/ in our tree? Should we aim for some consistency?
• The presubmit check would have to check that the dartfmt snapshot in the build output is not stale, and then ask for a rebuild if so.
• The presubmit check would rely on people routinely building the create_sdk target. This is not part of our regular workflow on the VM team, and I suspect people would find it disruptive.

[sigmundch]

For context, here are the two issues our team ran into:

• issue 1: some team members dogfood the bleeding-edge sdk in their editor daily. Because they run the formatter from the editor
• issue 2: some code-generation tools are invoking the formatter by importing package:dart_style and calling its APIs.

Both of these end up using the version of dart_style pulled in to third_party/pkg/.

Just thought of a different idea: ensure that we update the sdk under tools/ together when rolling the dart_style package (and only update the DEPS file entry for dart_style when we can build such SDK).

If we do this, then:

• The PRESUBMIT is consistent with the formatter in master, so both issues I mentioned above are addressed.
• We don't depend on building a formatter locally, so we don't need to deal with the second and third issue that Zach brought up above.

@munificent @whesse - would you be OK with this change in how we roll dart_style? Can we establish a protocol or even a test that ensures rolls of dart_style respect this policy?

[whesse]

It would mean uploading a bleeding-edge version of the SDK to be downloaded by our checkout, rather than a recent dev version, or else, we just automatically make a new dev version whenever the dart_style package is updated in DEPS. This sounds doable, as long as it doesn't happen more than once or twice a week. It takes about 15 minutes to upload a new version, once the dev version is built.

[munificent]

dart_style doesn't change very often, so I'm fine with syncing it to dev releases. We just have to figure out how the handshake for that goes so that the right things happen in the right order.

Would it make sense for me to just file a tracking issue requesting pulling the latest dart_style into the DEPS file and the infra folks can do that at the same time that they cut a new dev build?

[whesse]

That sounds fine. And if there isn't a build scheduled soon, we can just do one for this purpose. Even just patch the last dev build with only that change, so we know it is stable.

[sigmundch]

Fantastic! thanks @munificent and @whesse!

I'll create a CL shortly to add a comment in the DEPS file to make sure people follow the protocol if for any reason someone else is pulling a new version of dart_style

[sigmundch]

landed documentation about the new process in e8b6af0