Json_serializable.dart: Request for adding support to generate the code in a separate folder to keep the main code directory clean

[mayur-padshala]

Hi.
This is really a feature request. Can you modify this awesome library to accept some the folder name as part of the part 'somefile.g.dart' ? Example: part './generated/somefile.g.dart' ? This would really help to keep our main source files directory clean.

[mayur-padshala]

This should be easy with relative paths.

I created a folder - generated and moved all the *.g.dart files to this folder.
Then, I had to change the line part of 'somefile.dart' to part of '../somefile.dart'
And inside the source files, the line that says part 'somefile.g.dart' to part './generated/somefile.g.dart'

The project runs perfectly fine without complaints and everything runs just okay.

But can you change the code to accept the directory as well and relieve us from modifying the generated files manually?

[mayur-padshala]

And it will be much better if you can add the project name from pubspec.yaml and use full paths like:
part 'package:project_name/folder_name/somefile.g.dart'
And
part of 'package:project_name/some_other_folder/somefile.dart';

This would be much useful when refactoring / moving the files using Android Studio - It will automatically refactor the paths as well. :smiley:

[kevmoo]

Our code generation model is very optimized around emitting generated files next to their source files.

RE using 'package:' URIs for parts, I'd argue this is a bug in our editing tools that they don't handle moves better.

[mayur-padshala]

It is annoying to have more than 30 *.g.dart files in my source code directory and is not easy to maintain.
Moreover, I would argue too in favor of efficiency of the editing tools: Android studio does refactor the files automatically to have correct package: paths when files are moved around. I have had no issues in refactoring as it is an IntelliJ based IDE, it is simply the best.

[kevmoo]

@jakemac53 @natebosch – thoughts here?

[jakemac53]

We have had a fair number of valid requests for generating code in a separate directory instead of right next to files. The primary thing we are lacking is a solid proposal for how to handle this with static config (in build.yaml).

Note also that for the json_serializable case specifically it is more challenging - you would have to either have a way of overriding the static config for that builder for a specific target, or create your own special builder which utilizes whatever static config we decide is necessary to support this.

Ultimately, the simplicity of the current approach has a lot of benefits, which is why we haven't attempted to solve this issue.

Given a concrete enough proposal for how to resolve it, we could consider something though.

[natebosch]

Related request in build: https://github.com/dart-lang/build/issues/1689

Although it sounds like this is a request also to make it user configurable which would take https://github.com/dart-lang/build/issues/683 as well

This is not nearly as easy as it would seem. The non-configurable case is tractable - if we want json_serializable (or source_gen in general - but that would be way tricky to roll out) to _always_ output to a directory _always_ named generated we could probably do that, but it still has downside like expanded configuration surface area that most users won't need, and we'd have to make the choice for all users of json_serializable at once.

If we want to user to decide when to output to a separate directory and what it should be named the difficult jumps up dramatically. See the above linked issue for some discussion.

It also sounds like the original request was for the output location to be determined by the part directive in the file. This can't ever be accomplished - we cannot determine outputs based on file content. If anything, and it's very unlikely, the configuration for output directory would need to be in build.yaml

[bagintz]

What about an annotation in the source file that says where to put the part?

[natebosch]

What about an annotation in the source file that says where to put the part?

See the linked discussion - we need to know statically, without reading any of the input files, what outputs can exist and where they'd come from. This is what enables to lazily trigger builds.