latest update graphs 2.3.0 ruined common annotations json & hive in build_runner

[forsytalnd]

I dunno if this is your issue, but...
Your library is in dependencies in build_runner and after last updating 2.2.0 --> 2.3.0 an issue was happened.

When there are both annotations in class, like that,

part 'user.freezed.dart';
part 'user.g.dart';

/// Класс пользователя для авторизации
@freezed
class AuthUser with _$AuthUser {
  /// Базовый класс typeId: 0, adapterName: 'AuthUserAdapter'
  @HiveType(typeId: 0)
  const factory AuthUser({
    @HiveField(0) required String id,
  }) = _AuthUser;

  /// AuthUser.fromJson
  factory AuthUser.fromJson(Map<String, dynamic> json) =>
      _$AuthUserFromJson(json);

json_annotation which is indirectly called from freezed had been adding its annotations in ".g.dart" alongside with hive

part of 'user.dart';

// **************************************************************************
// TypeAdapterGenerator
// **************************************************************************

class AuthUserAdapter extends TypeAdapter<_$_AuthUser> {
  @override
  final int typeId = 0;


// **************************************************************************
// JsonSerializableGenerator
// **************************************************************************

_$_AuthUser _$$_AuthUserFromJson(Map<String, dynamic> json) => $checkedCreate(
      r'_$_AuthUser',
      json,
      ($checkedConvert) {
        final val = _$_AuthUser(

As a result of last night updating of graphs json generator overrides file .g.dart and previous info disappears.

I added this issue to build_runner repository too.

[spioc999]

I had a similar issue.
As also mentioned in this thread, I was able to solve the issue by adding these lines in pubspec.yaml

dependency_overrides: 
  graphs: 2.2.0 

But, please, fix it!

[jakemac53]

cc @nex3 I wonder if the changes to topologicalSort and stronglyConnectedComponents broke this somehow, looking into it though.

[jakemac53]

I do see a difference in builder ordering here - specifically hive_generator now appears before freezed.

These packages presumably don't depend on each other and so the order is undefined technically - either is a valid topological sort.

However it appears that hive_generator does rely on running second today? And it isn't giving any sort of error which it probably should be.

[jakemac53]

cc @natebosch

[jakemac53]

Adding this configuration to your build.yaml should fix the issue:

global_options:
  freezed:
    runs_before:
      - hive_generator

[jakemac53]

I am not sure if it is worth trying to revert the ordering behavior of this package back to what it was previously or not. It is explicitly not defined, and builder ordering is similarly explicitly not defined if there is no explicit configuration via runs_before.

[jakemac53]

We could also do a separate ordering pass in build_runner potentially.

[jakemac53]

@spioc999 @forsytalnd can you try the config above?

[jakemac53]

Also cc @rrousselGit technically I think freezed could add this configuration directly, although its a bit weird for you to do so, I believe it is allowed to be there even if a project doesn't depend on hive_generator. A bit of a slippery slope potentially though.

[gaetschwartz]

@jakemac53 in my case, I already had an ordering defined using runs_before, which used to work before but doesn't with the latest graph update:

[...]

global_options:
  drift_dev:drift_dev:
    runs_before:
      - riverpod_generator:riverpod_generator
  freezed:freezed:
    runs_before:
      - drift_dev:drift_dev

[rrousselGit]

Yeah I don't want to do this. It'd get weird very quickly

But I wonder if this bug is related to dart-lang/build#3503, which is a much more problematic issue I hit recently.
I could see a world where source_gen's combining_builder starts to run before the "parts" have been generated in the .dart_tool folder.
Although that's just a wild guess

Edit: Just tested reproducing dart-lang/build#3503 after a dart pub downgrade graphs and the issue does disappear.
So this wild guess might be true, ha.

[jakemac53]

@gaetschwartz can you provide some more info? What does your build.yaml file look like.

We should still be respecting any explicit builder ordering, what has changed is the undefined implicit ordering that happens when we don't have any explicit configuration.

[gaetschwartz]

Here it is, it now doesn't respect the first rule saying drift_dev should be ran before riverpod_generator.

targets:
  $default:
    auto_apply_builders: false
    builders:
      drift_dev:not_shared:
        enabled: true
        generate_for:
          - lib/**/drift.dart
          - lib/**/*.drift.dart
          - lib/**/*.drift
        # If needed, you can configure the builder like this:
        options:
          sql:
            dialect: sqlite
            options:
              modules:
                - json1
      riverpod_generator:riverpod_generator:
        enabled: true
      freezed:freezed:
        enabled: true
        generate_for:
          - lib/**/*.gen.dart
      json_serializable:
        generate_for:
          - lib/**/*.gen.dart
        enabled: true
        options:
          # https://pub.dev/packages/json_serializable#build-configuration
          explicit_to_json: true
          checked: true
          field_rename: snake

global_options:
  drift_dev:drift_dev:
    runs_before:
      - riverpod_generator:riverpod_generator
  freezed:freezed:
    runs_before:
      - drift_dev:drift_dev