Read on Twitter
Generated code:
I'm surprised to see so much support for not committing!
I think it's important that repos are buildable/testable immediately on clone — if your code uses e.g. types gen'd from a .proto, they should be present, right? I shouldn't need to call protoc-gen-go myself.
I think it's important that repos are buildable/testable immediately on clone — if your code uses e.g. types gen'd from a .proto, they should be present, right? I shouldn't need to call protoc-gen-go myself.
But I think it might all boil down to how you think about code generation as a concept —
Is it a stage of the build process, like linking?
Or is it an affordance for the developer, like autocomplete?
Is it a stage of the build process, like linking?
Or is it an affordance for the developer, like autocomplete?
If the source of truth and the generated code are close together, you can make the case for the build step.
But if they're far apart — like most proto-generated types, most mocks, etc. — then making it a build step couples the two things tightly together.
But if they're far apart — like most proto-generated types, most mocks, etc. — then making it a build step couples the two things tightly together.
That's often a mistake.
For example, mockable interfaces are consumer contracts, explicitly meant to decouple producer and consumer, and to permit [API compatible] drift. Regenerating the mock automatically when the producer changes subverts those properties.
For example, mockable interfaces are consumer contracts, explicitly meant to decouple producer and consumer, and to permit [API compatible] drift. Regenerating the mock automatically when the producer changes subverts those properties.
And .proto definitions are meant to be even stronger contracts, schemas, necessarily forward-compatible and with a lifecycle totally independent of the code that consumes them. Regenerating code from them should always be opt-in.
