'unawaited' is imported from both 'package:meta/meta.dart' and 'package:test_api/src/utils.dart'

[cooler-king]

INFO: 
INFO: [INFO] Connecting to the build daemon...
[INFO] Generating build script...
[INFO] Generating build script completed, took 345ms
INFO: [INFO] 
[INFO] Creating build script snapshot......
[INFO] 
[SEVERE] Failed to snapshot build script .dart_tool/build/entrypoint/build.dart.
INFO: 

INFO: [SEVERE] This is likely caused by a misconfigured builder definition.

INFO: [SEVERE] ...AppData/Roaming/Pub/Cache/hosted/pub.dartlang.org/test_core-0.3.7/lib/test_core.dart:69:5: Error: 'unawaited' is imported from both 'package:meta/meta.dart' and 'package:test_api/src/utils.dart'.    unawaited(Future.error('Dummy exception to set exit code.'));    ^^^^^^^^^```

[natebosch]

This should be fixed with a pub upgrade as long as you can pic up test_core version 0.3.10.

See #1292

[cooler-king]

I can't get test_core 0.3.10, even with an override; it's incompatible with angular alpha.
pub global activate webdev gets meta 1.2.1 and then the webdev serve build crashes. I haven't been able to find workaround yet @natebosch.

[cooler-king]

I was able to get our builds working again by following the suggestion here: dart-lang/build#2745 (comment)

However I still can't get the builds to work without that workaround.

[natebosch]

In the short term I'd recommend pinning to an older meta

dev_dependencies:
  meta: 1.1.8

[natebosch]

@vsmenon - can you help us understand how we should prioritize this issue.

background - meta was published with a new unawaited API which is technically breaking but is in the realm of technically breaking changes that we normally treat as non-breaking. test_core happens to be a place that was broken by this. We were able to work around this and be backwards/forwards compatible across versions of meta, but only in the very latest test_core. Current angular users can't pick up the latest test_core.

Current angular has a constraint on analyzer at ^0.38.3.

The current test_core (which has a workaround for this change in meta) as a constraint on analyzer at >=0.39.5

So there are three paths forward I think:

• Recommend that angular users pin to an older meta in the long term.
• Backpublish a version of test_core forked from sometime when it had an older analyzer constraint. We'll need to be very careful about versioning and both test_core and test need to be published.
• Republish angular with a higher upper bound constraint on analyzer. I have significant doubts that this is feasible - I don't know what breaking changes in analyzer would impact angular at the version where it is currently published.

[kevmoo]

Talked to @vsmenon – we agreed that telling folks to pin pkg:meta is the easiest path in the short term.

We also agreed to we need to find a way to validate "the ecosystem" when we roll these types of changes to heavily used packages

[vsmenon]

Talked to @vsmenon – we agreed that telling folks to pin pkg:meta is the easiest path in the short term.

If I understand this correctly, it buys us time until we publish angular again, at which point users don't need to pin?

We also agreed to we need to find a way to validate "the ecosystem" when we roll these types of changes to heavily used packages

Yes. If we had something akin to the Flutter HHH bot for AngularDart, would that have caught this?

fyi - @sigmundch

[natebosch]

If I understand this correctly, it buys us time until we publish angular again, at which point users don't need to pin?

At the time we publish angular there will be breaking changes. Users who upgrade to the new angular won't need to pin meta anymore.

[filiph]

Just want to say, for what it's worth, that this is not only a problem with angular. My CI builds are broken, yet they don't use angular.

For whatever reason, Google didn't direct me here when I was searching for the exact error. Not sure why, since it's quoted in the @cooler-king's OP. Pasting it in here just to give the search engine another hint: Error: 'unawaited' is imported from both 'package:meta/meta.dart' and 'package:test_api/src/utils.dart'.

[lrhn]

meta was published with a new unawaited API which is technically breaking

Adding a top-level declaration is well within the bounds of what we consider non-breaking. It only warrants a minor version increment.

It can break code, but any change can break code. Running pub upgrade is not a safe operation, but it should be one with a simple workaround for any new conflicts.

For an added top-level declaration conflicting with an existing one, the workaround is to hide one of them. That's what should happen anywhere the new unawaited causes a problem, If the conflict is in a dependency, the alternative is to ask for an older version of meta until your dependencies are ready.

Is there something about meta or pedantic which makes this change more complicated than if, say, package:async had added unawaited? (Something other than package:meta being used a lot more).

[jakemac53]

Note that the change here is being reverted due to it being much more breaking than anticipated.

The release of these packages was built on an assumption that the vast majority users would get all updated packages at the same time. This ended up meaning 3 different packages (meta, pedantic, test_core).

This ended up not being the case for a large number of users - and would cause further issues if not rolled back once flutter pinned the new meta, which is why we are reverting.

Some of the breaking cases are:

• Users that pin pedantic to keep their lints stable (they should be using the versioned analysis_options.yaml files to do this, but not all people are aware of that).
• Users on old SDK versions won't get the latest test_core.
• Users depending on angular won't get the latest test_core due to the analyzer constraints in angular.
• Users unable to get the latest analyzer for any other reason won't get the latest test_core.

[jakemac53]

The revert has now happened, I am going to close this issue. If anybody is still seeing problems please bring them up though.