You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most codegen uses the formatter to create a consistent and readable output. The formatting always happens in the same builder as the code generation. This means that even when a builder produces identical output it pays the cost to reformat.
If it was more common to have a build_to: cache intermediate asset with the unformatted Dart code and formatted it in a separate build step then we would often short circuit the formatting steps.
Or maybe we could look at something like a way to record a hash of the "meaningful" input from read assets or a fingerprint of preformatted generated code. This would be a bit like baking in the pattern we've used in some code generators where we first read information into a JSON asset which can short circuit any builders that use it as input, then a separate build step reads the JSON asset to produce formatted code.
The text was updated successfully, but these errors were encountered:
One problem (or feature) with formatting separately is that depending how it is done it can affect the visibility of the files to other builders.
We could have a global builder that just formats files, after all codegen is done, which would mean no builder that opts into that can see the outputs of any other builder.
Or we could go the other way and say each builder should set up its own formatting builder, which only formats its own output. That could run immediately after it runs, so its output is available to other builders.
Most codegen uses the formatter to create a consistent and readable output. The formatting always happens in the same builder as the code generation. This means that even when a builder produces identical output it pays the cost to reformat.
If it was more common to have a
build_to: cache
intermediate asset with the unformatted Dart code and formatted it in a separate build step then we would often short circuit the formatting steps.Or maybe we could look at something like a way to record a hash of the "meaningful" input from read assets or a fingerprint of preformatted generated code. This would be a bit like baking in the pattern we've used in some code generators where we first read information into a JSON asset which can short circuit any builders that use it as input, then a separate build step reads the JSON asset to produce formatted code.
The text was updated successfully, but these errors were encountered: