Add ability to generate copyWiths in one place
dalewking opened this issue · 4 comments
The way you currently are set up for every file that has CopyWith you generate a .g file next to it and have to add the part statement, but that generates a lot of files if used all over the place and is messy. Since these are extension methods and do not need special access to the class via part I think it would be nice if you could generate multiple extensions in one file.
One simple way to that would be to have a location property on CopyWith that specified a path to generate the file to. So for example I could have a bunch of classes annotated with
@CopyWith(location: 'copiers.dart')
And instead of generating a .g file for each file it generates a single file copiers.dart that has all the extensions in it.
I thought about a more complex scenario where the CopyWith lets you specify a group name and then a separate annotation (or perhaps it is in the pubspec) that tells you where to generate each group. I suppose you could do it all with just location and group properties on CopyWith:
- if you specify neither it works as it does currently generating a .g part file
- if you specify just a location it will be generated in a file at that location like alI described above.
- if you just specify a group it adds that to a group, but by itself does not generate the file
- If you specify both (and this combination would not be on an immutable class but on some other construct e.g. your main method) it would say generate all copiers for this group at this location.
Another way to implement it would be to pass a list of types to CopyWith (or perhaps it is a new annotation) and it generates the copier extensions for the referenced types. This also has the advantage of allowing you to create copiers without modifying the class.
Hey @dalewking. Thank you for the suggestion. I see how this can help with organising your code in some cases. The problem is that we don't really have control over it as this structure is implied by the build_runner
and this library is literally a plugin for it. I don't think that this is possible with a meaningful amount of effort.
While I have not written a builder plugin, I do not think that is the case. If you are using a SharedPartBuilder you do not really control the location, but from what I read with the LibraryBuilder you can generate a standalone dart file
Probably this is possible, I haven't done much investigation in this direction.
Still, in my personal opinion, the approach with separating every generated file much versatile. My main point is that by keeping them separately allows you to precisely use them exactly where you need them. On the other hand, if you generate everything in a single file you will end up with a file that has a number of dependencies that you will be forced to include everywhere where you use any individual extension.
It is a trade-off. If I have 10 files that I want copiers for then I end up having 10 additional files for the copiers. I would rather roll that into one.
Also my suggestion at the end for an annotation that you provide a new annotation that takes a list of classes to generate should be easier to implement.
But I feel you should leave this issue open instead of closing it. My suggestions have merit and by leaving it open you might get someone to do a PR for it.