build_resolvers error with latest analyzer + next flutter stable

[jakemac53]

The flutter SDK has // @dart=2.9 comments in it, meant to opt it in, but the latest analyzer now requires language version 2.10 (regardless of the current sdk version).

I don't know the best way to resolve this, soon flutter will presumably have the // @dart=2.10 comments (it will have to), but all old flutter sdks would be broken with build_runner if users get the latest analyzer.

cc @scheglov @leafpetersen @natebosch

[jakemac53]

Note that when the next flutter stable lands any time a user runs pub upgrade they will mostly likely hit this issue (assuming they get the latest analyzer).

The only recommendation we can give those users as far as i know is to pin their analyzer version to something older.

[franklinyow]

@franklinyow

[leafpetersen]

Ok, summarizing some discussion.

• The flutter engine web port landed with some // @dart=2.9 comments for opting libraries in. These should be removed (they have been changed to // @dart=2.10 in the current master). cc @yjbanov They should be unnecessary.
• The current flutter stable will go out with a 2.9 sdk, and with those comments listed as // @dart=2.9
• The analyzer package has a wide sdk constraint, and the latest published version claims that it will work with a 2.9 sdk , so it will be picked up by users on flutter stable with dart 2.9 cc @stereotype441 @scheglov @devoncarew
• The latest published version of the analyzer treats // @dart=2.9 as opting code out rather than in

As a result of the above, build_runner users (and any other users who use the analyzer package to analyzer the flutter sdk) will get broken unless they pin to an older version of the analyzer package.

Options to proceed:

• Do nothing. build_runner users will get broken and will need to pin to an older analyzer. cc @kevmoo
• Try to get a cherry pick into flutter stable to remove the //@dart=2.9 comments. This should be a no-op as far as flutter itself is concerned, but it's late (possibly even mechanically too late) in the release cycle for this. cc @pcsosinski
• Publish a new analyzer that supports both 2.9 and 2.10 as an opt in. This doesn't fix the breakage, but it does make pub upgrade work as a solution (and apparently this path to breakage exists independently of language versioning).
• Publish new versions of build_runner with tight sdk constraints that pin the appropriate analyzer? cc @jakemac53 does this work?

[jakemac53]

Another wrinkle I just realized here is all the allow listed packages will also have a problem. They have a 2.9 language version as well (as specified by their sdk constraint) and will not be properly opted in. So just fixing the flutter libraries won't fully resolve the issue, although it will allow us to summarize the SDK properly.

Any imports to package:flutter will have transitive errors in build_runner builds, and any direct imports of allow listed packages will also have errors.

[jakemac53]

Posting here so I don't forget, but I noticed that build_resolvers also relies on the existing experiments spec which says they only work on the current version. We need to remember to remove that check if the behavior changes.

[pcsosinski]

Ok, summarizing some discussion.

• The flutter engine web port landed with some // @dart=2.9 comments for opting libraries in. These should be removed (they have been changed to // @dart=2.10 in the current master). cc @yjbanov They should be unnecessary.
• The current flutter stable will go out with a 2.9 sdk, and with those comments listed as // @dart=2.9
• The analyzer package has a wide sdk constraint, and the latest published version claims that it will work with a 2.9 sdk , so it will be picked up by users on flutter stable with dart 2.9 cc @stereotype441 @scheglov @devoncarew

this seems like a bug. can it be fixed and published?

• The latest published version of the analyzer treats // @dart=2.9 as opting code out rather than in

As a result of the above, build_runner users (and any other users who use the analyzer package to analyzer the flutter sdk) will get broken unless they pin to an older version of the analyzer package.

Options to proceed:

• Do nothing. build_runner users will get broken and will need to pin to an older analyzer. cc @kevmoo
• Try to get a cherry pick into flutter stable to remove the //@dart=2.9 comments. This should be a no-op as far as flutter itself is concerned, but it's late (possibly even mechanically too late) in the release cycle for this. cc @pcsosinski

it would have to be ready to go (tested on branch) by Thursday of this week. but based on @jakemac53's comments below I'm not sure if it's going to solve us.

• Publish a new analyzer that supports both 2.9 and 2.10 as an opt in. This doesn't fix the breakage, but it does make pub upgrade work as a solution (and apparently this path to breakage exists independently of language versioning).
• Publish new versions of build_runner with tight sdk constraints that pin the appropriate analyzer? cc @jakemac53 does this work?

[jakemac53]

this seems like a bug. can it be fixed and published?

We need to think more about how this interacts with the old versions that are published and have wide sdk constraints. Because those do exist the concern is that people end up with really old analyzer versions which puts you in a similar situation.

At least as far as the immediate issue is concerned, it wouldn't help because there is a current published version whose current language version is 2.10 and has a wide constraint, so publishing a new version will just result in users getting the existing one.

We could possibly however do the following, and it might work for more users than not:

• publish a new version 0.39.16 which is identical to 0.39.14, except with an sdk constraint like >=2.9.0-0.0 <2.10.0
• publish a new version 0.39.17 which is identical to 0.39.15, except with an sdk constraint like >=2.10.0-0.0 <2.11.0

This would make it so most users would not get the "bad" 0.39.15 version, pub would instead choose one of the newer versions, at least until 2.11 at which point we would need a new analyzer or else users would get the older 0.39.15 version again.

[devoncarew]

To paraphrase the last solution a bit:

publish a new version 0.39.16 which is identical to 0.39.14, except with an sdk constraint like >=2.9.0-0.0 <2.10.0
publish a new version 0.39.17 which is identical to 0.39.15, except with an sdk constraint like >=2.10.0-0.0 <2.11.0

This helps us because we want people on the 2.9 SDK to be able to use // @dart=2.9 to opt-into NNBD, and people on 2.10 to be able to use // @dart=2.10.

If that's correct, the dual publish of package:analyzer sounds like a reasonable solution (solves the issue, and low-risk for further complications).

edit: thinking about this more, I'd be concerned about how we'd get package:analyzer api changes or fixes to users on dart 2.9; that'll be the stable version for ~3 months

We could publish the experiments flag info as a package, and put sdk constraints (^2.9, ^2.10) on that?

[jakemac53]

We are going to do a temporary fix here to pin the analyzer, longer term we have a plan to change how experiment language versions work, such that they can be pinned to a certain version instead of the "current" version which caused a lot of pain when switching from 2.9 -> 2.10.