I’d like to propose support for generating code that is fully self-contained, without depending on external runtime/helper packages.
To reduce dependency footprint and supply-chain risk, I would strongly prefer generated output that relies on the Go standard library wherever possible, rather than importing additional packages for helpers, types, validation, marshaling, parameter binding, and other runtime behavior.
The main motivation is to make generated code easier to adopt in stricter environments where we want:
- fewer external dependencies
- simpler auditing and vendoring
- less version coupling between generated code and helper libraries
- more explicit, verbose generated logic instead of hidden/runtime behavior
- code that is easier to copy, inspect, and maintain internally
In short, we would prefer the generated code to be self-contained, even if that means the output is more verbose.
A few thoughts on scope:
- a config option for “self-contained” or “no runtime deps” generation would be ideal
- generated code could inline helper types/functions instead of importing them from external packages
I realize this may involve tradeoffs in generated code size and maintenance burden, so I wanted to ask first whether this direction would be welcome.
If the project is open to receiving this change, I’d be happy to contribute an implementation.
I’d like to propose support for generating code that is fully self-contained, without depending on external runtime/helper packages.
To reduce dependency footprint and supply-chain risk, I would strongly prefer generated output that relies on the Go standard library wherever possible, rather than importing additional packages for helpers, types, validation, marshaling, parameter binding, and other runtime behavior.
The main motivation is to make generated code easier to adopt in stricter environments where we want:
In short, we would prefer the generated code to be self-contained, even if that means the output is more verbose.
A few thoughts on scope:
I realize this may involve tradeoffs in generated code size and maintenance burden, so I wanted to ask first whether this direction would be welcome.
If the project is open to receiving this change, I’d be happy to contribute an implementation.