Generate code in another folder?

[dam0vm3nt]

I think it could be interesting to group all the generated code in different folder from the original sources.
this makes simple to distinguish main source files from generated one (that one should not edit by hand).

Is it possible to add some options to PartBuilder and LibraryBuilder in order to specify a different folder (even restricted to lib) where to put generated files ?

[jakemac53]

Seems reasonable, I think we probably would want to keep outputs in the same top level directory (lib/web/etc) as the original inputs, and then mirror the rest of the path under the generated files directory.

So if you had a file at lib/src/models/model.dart and set your output dir to lib/src/generated, we would output the part file at lib/src/generated/src/models/model.g.dart.

What do you think?

The main issue I see is that the part statements would be pretty long/ugly. However we need to mirror the directory structure to make sure we don't have conflicts....

[dam0vm3nt]

LGTM

I don't think the part import path is actually a problem. To me it is preferably compared to having generated files mixed with original one.

[natebosch]

This won't be easy but should be feasible. Do we need it to be configurable or should it be a boolean flag on Builder and we hardcode the directory name? Is it worth the extra cognitive load of having a new field on Builder - how much will it get used? How will the builder find the AssetId, will we need a new utility there like AssetId.inGeneratedDirectory?

Is this a property of the code generator, or of the usage? If you're using built_value should you get to choose to use the generated directory, or would you need to file an issue requested that it uses the generated directory?

[jakemac53]

Ah ya I guess this is more challenging than I realized at first because of the migration away from declareOutputs and to a direct file extension conversion... originally I wasn't thinking we would need any changes in package:build.

[jakemac53]

Also fwiw we are moving more towards not outputting files in the main source directory any more, but instead outputting them to a hidden directory and then materializing a merged view in some output folder.

This is because we are adding support for generating files in other packages so we have to create our own view of the world to prevent ourselves from polluting the users pub cache.

Once we are fully migrated over to this model then that probably closes this issue as well?

[natebosch]

I think there could still be a use case for generating files to a side directory and committing those files and uploading them to pub, though I'd also be happy to hear that just building to a cache solves the issue.

[dam0vm3nt]

ouch! I couldn't imagine this was so complicated. I thought there was no such a difference where the generated file was. Why having it beside the original file should be so different than having it in a different path ?

[zoechi]

@natebosch I prefer committing generated files.
This way I always see what changes modifying the generator causes in the generated output.

[jakemac53]

@zoechi we do plan to support that model as well, but it hasn't turned out to be as useful as we originally hoped. I think we will probably end up with some sort of mixed mode where certain Builders are outputting to a cache dir and others output directly in your source dir like happens today.

[zoechi]

@jakemac53 that sounds fine. I also find both cases useful.

[matanlurey]

Can we close this since build_runner is basically supporting this going forward?

[jakemac53]

Ya, lets close this as not planned/obsolete based on new changes