build_runner throwing error while using json_serializable

[boylenssen]

• Dart SDK Version (2.5.0)
• build_runner 1.6.7

I'm on MacOS.

Reproduce steps:
create project flutter create <some_project>.
Add de dependencies to use json_serializable => json_serializable: ^3.2.2, dev_dependency: build_runner: ^1.6.7

Run flutter packages pub run build_runner build -v

Pubspec and command output attached.
build_runner_output.txt

pubspec.lock.txt
pubspec.yaml.txt

[boylenssen]

Attached are 2 projects, they look identical too me, but one of them gives no issues, the other throws the error when running these commands:

flutter clean
flutter packages pub run build_runner build --delete-conflicting-outputs

NOT_working_version.zip
working_version.zip

edit:

Seems like a different analyzer version. I redownloaded the Flutter SDK to rule it out and changed it back later. What does determine the analyzer version?

[boylenssen]

Workaround for now: setting the version of the analyzer in the pubspec.lock file from 0.38.3 to 0.38.2

[jakemac53]

The analyzer version is selected by pub based on the constraints in your package and your transitive deps. For flutter projects this will largely be determined by whatever version flutter has pinned for a package, because they pin very specific versions that they have actually tested.

EDIT: It doesn't look like flutter has an analyzer dep though so regular version solving should happen here.

See also https://github.com/dart-lang/build/issues/2450

[jakemac53]

cc @stereotype441 do you know if this was an intended change or what we should be doing here?

[conghaonet]

downgrade analyzer version from 0.38.3 to 0.38.2

dependencies:
  //analyzer: ^0.38.2
  analyzer: 0.38.2

[dianyij]

after downgrade analyszer, run flutter pub get

[scheglov]

I found the reason why it does not work with the stable version of Flutter SDK.
Currently this is version https://github.com/dart-lang/sdk/commit/1ef83b86ae637ffe7359173804cbc6d3fa25e6db.

This version did not have summary2 enabled, and my mistake was that it was building summary1 or summary2 of Dart SDK depending on the state of the useSummary2 flag, landed as this. This is the version that was included into the stable Flutter SDK.

I corrected it in a following up commit. But it was too late, the stable version does not include it.

And the latest version of analyzer switched to summary2, and when used as a library and given the Dart SDK summary, expects to find the summary2 version of summary.

[jakemac53]

It sounds like that version of the analyzer should have had a minimum sdk constraint in it? The best fix I am aware of is to publish a +1 revert release, then a new release with the sdk constraint updated.

[stereotype441]

@jakemac53 that seems reasonable as a short term fix, and we can do that. But I have a long term concern: It sounds like the build_runner is relying on versions of analyzer published in pub being able to consume summaries produced by the SDK. Soon we want to land a change in SDK master that stops producing summary1. At the time we do that, anyone using build_runner with an older version of the analyzer that was before the summary2 work will be broken, and we can't fix things for them by publishing a new analyzer version.

The fact is that we don't guarantee analyzer compatibility between summaries produced by different versions of the analyzer, which means that any tool that passes summaries into the analyzer needs to ensure that the summaries passed in were generated by the same version of the analyzer as the version that's consuming them. It sounds like build_runner isn't doing that. Is there any way to change it so it does?

I'm happy to talk about this in a VC.

[jakemac53]

We do consume the SDK summary itself and feed that into the analyzer (which is used as a library), but that is the only summary we use externally any more.

If we need to stop consuming that summary we could do that but it would slow down startup time a lot. Maybe we could produce our own summary of the sdk and re-use it or something instead?

[stereotype441]

@jakemac53 Yeah, producing your own version of the summary sounds like a good approach. @scheglov could you work with Jake to figure out an appropriate analyzer API to make this possible?

[scheglov]

Discussed with @jakemac53.

There is already summary builder, and we probably don't need to duplicate it via new function.
So, SummaryBuilder.forSdk(sdkPath).build() will build the summary, and package:build will call it and cache results as necessary.

[scheglov]

This is now even more important to fix, see dart-lang/source_gen#430

[jakemac53]

Note that we just got broken by the dev release (2.6.0-dev.2.0) it looks like so we have to fix that first (our presubmit bots are broken), and its unclear how long that will take.

[jakemac53]

unblocked our presubmits by pinning an old sdk (2.6.0-dev.1.0) so I can start working on this