When a builder generates parts using build_to:cache instead of build_to:source, and the parts use URIs in their part of directives, the part files don't get recognized correctly and you get a part_of_different_library error.

This issue seems to be specific to the analyzer, and does not seem to impact running in the VM or compiling to JS files that depend on those generated parts.

For example, if you have a file foo.dart which pulls in a generated file:

part 'foo.g.dart';

// ...

and the generated file looks like:

part of 'foo.dart';

// ...

Then you get an error on the part URI in the foo.dart file that looks like:

Expected this library to be part of
'file:///<path_to_package>/example/foo.dart', not
'file:///<path_to_package>/.dart_tool/build/generated/foo_package/example/foo.g.dart'.
Try including a different part, or changing the name of the library in the part's part-of directive.

I put together a package with a simple builder that reproduces this issue, which can be seen on this line.

However, if the generated part points to the main library using its library name, there's no error. For example, if you have a file foo.dart which pulls in a generated file:

library foo;

part 'foo.g.dart';

// ...

and the generated file looks like:

part of foo;

// ...

In that case, everything seems to work fine. Example of that behavior here.

Impact

This impacts consumers of over_react, which uses build_to:cache for its generated code.

It'd be ideal if this issue were fixed in the Dart SDK, and released in a 2.x version. I'd be happy to attempt to contribute a fix if that would be helpful!

If that's not feasible, then the following workarounds come to mind:

1. switching to build_to:source
2. generating parts using library names if they're available, and encouraging consumers to declare names on source libraries

While switching to build_to:source would be possible, it'd be no small mount of work to migrate consumers. I think ideally we'd stick with build_to:cache until Dart macros are available :).

Dart SDKs

I tested this issue in different stable Dart SDKs until I could narrow down where behavior changed.

In Dart <=2.15.1, this worked as expected.

In Dart >=2.16.0 <=2.17.7, part directives in libraries that point to generated parts have uri_has_not_been_generated errors, regardless of whether a part uses a URI or library.

In Dart >=2.18.0, part directives in libraries that point to generated parts have part_of_different_library errors, but only if those parts uses URI in their part of directives, and not if they use library names.

This issue is still present the beta (2.19.0-444.4.beta) and dev (3.0.0-128.0.dev) channels as well.

You can see CI runs of that reduced test case package on different Dart SDKs here.