mrgnhnt96 / autoequal Goto Github PK

Hey @SunnyDayDev 👋

I thought we'd make an issue to transfer ownership, that way we can communicate about what actions are taking place and when.

I accepted the invite to the publishers on pub.dev. You (or I) can transfer the ownership of the package whenever you'd like.

For the repository, I haven't gotten any invites yet to transfer the ownership of the repo.

If there is anything that you need me to do, please let me know.

Looks like 1f4cd66 broke the generator when used with analyzer: ^5.0.0.

DartType.element has been deprecated in v4.4.0 and removed in v5.0.0. It will have to be migrated to DartType.element2.

I'll submit a PR later.

Cont. from #9

Looks like _autoequalProps includes setter methods, even when there is no getter method provided.

The reason that setters are included is because they are technically FieldElements, with a distinguishable flag, isSynthetic. A simple check here to exclude the element from the list should solve this issue.

import 'package:autoequal/autoequal.dart';
import 'package:equatable/equatable.dart';

part 'fake_class.g.dart';

@autoequal
class FakeClass extends Equatable {
  const FakeClass({
    required this.a,
  });

  final String a;

  set c(String value) => print(value);

  @override
  List<Object?> get props => _autoequalProps;
}

// GENERATED CODE - DO NOT MODIFY BY HAND

part of 'fake_class.dart';

// **************************************************************************
// AutoequalGenerator
// **************************************************************************

extension _$FakeClassAutoequal on FakeClass {
  List<Object?> get _autoequalProps => [a, c];
}

Hi, I really love this package as it makes working with Equatable a breeze.

Would you mind upgrading analyzer in autoequal_gen to

analyzer: '>=4.7.0 <6.0.0'

Just came across your package, it looks super useful and I'm really interested in using it.

Ran a couple of use cases and found that the _autoequalProps includes getter methods by default. I think that the ability to include getter methods is useful but should not be default. I use getter methods as a way of extending the functionality to my classes with the data/fields already provided, not necessarily as a new prop.

A possible solution for this would be to add an option to the build.yaml file

targets:
  $default:
    builders:

      autoequal_gen|autoequal:
        enabled: true
        options:
          include_getters: true

Or to annotate the element with either @ignoreAutoequal or @includeAutoequal for one off scenarios

The reason that getters (and setters, but I'll create another ticket for that) are included is because they are technically FieldElements, with a distinguishable flag, isSynthetic. A simple check here to exclude the element from the list should solve this issue.

import 'package:autoequal/autoequal.dart';
import 'package:equatable/equatable.dart';

part 'fake_class.g.dart';

@autoequal
class FakeClass extends Equatable {
  const FakeClass({
    required this.a,
  });

  final String a;

  String get b => 'b';

  @override
  List<Object?> get props => _autoequalProps;
}

// GENERATED CODE - DO NOT MODIFY BY HAND

part of 'fake_class.dart';

// **************************************************************************
// AutoequalGenerator
// **************************************************************************

extension _$FakeClassAutoequal on FakeClass {
  List<Object?> get _autoequalProps => [a, b];
}

When trying to generate the code for my abstract class, a severe error occurred:

[SEVERE] autoequal_gen:autoequal on .../counter_bloc.dart:

abstract class CounterEvent extends Equatable is abstract. Autoequal doesn't support abstract classes.

The target class:

@autoequalMixin
abstract class CounterEvent extends Equatable {
  const CounterEvent();
}

The error message is clear, but what's keeping autoequal from generating the code for abstract classes?

Even though equatable is made for immutable objects, it can be used on mutable objects.

In cases like this, should we include the mutable fields? I think its possible to do a check for if the field isFinal. Even then, it could be declared and assigned at the same time (like a list, eg: final list = <String>[];.

At the very least we could probably loop through the constructors and see if it exists within a constructor?

Not sure how to handle this one yet..

Hi, Are you going to migrate this package to null-safety?
Or will you accept PR if I do?

now the version is V2.0.5, but in this, is V1.11.5, Could you upgrade it