Use of text/template is causing DCE (dead code elimination) to be disabled
Short description
text/template usage is causing DCE (dead code elimination) to be disabled for opa and any application depending on it.
Use of text/template outside of tests should be avoided or replaced with another templating library
imports:
https://github.com/open-policy-agent/opa/blob/b86ad9f3e6cb7ef291e87ad5cdc2f7256a9d8700/v1/topdown/template.go#L5
https://github.com/open-policy-agent/opa/blob/b86ad9f3e6cb7ef291e87ad5cdc2f7256a9d8700/internal/gojsonschema/errors.go#L7
https://github.com/open-policy-agent/opa/blob/b86ad9f3e6cb7ef291e87ad5cdc2f7256a9d8700/internal/gojsonschema/schema.go#L34
Steps To Reproduce
- build opa or add a dependency on the opa go package
- observe large binary with DCE disabled
Expected behavior
Small binaries with DCE enabled
Additional context
See https://github.com/golang/go/issues/72895
Thanks for raising this! This is the first time I hear about it, but that's certainly unfortunate. I don't think the size of OPA's own binary is likely to be a problem for most users (~45 MB using the -static version without Wasmtime bundled), but I can certainly see how it could be for downstream projects if it eliminates DCE entirely. Which seems like an issue that at least from my naive understanding would need to be fixed in Go.
Also, thanks for pointing out the locations where this import exists in OPA. As we have a built-in function that pretty much does nothing but to mirror the Go function, we can't realistically have it removed without breaking existing deployments. So "replaced with another templating library" sounds like it would be the best option here... but I doubt there is one that is 100% compatible in behavior but without relying on the same APIs that have DCE disabled?
Only other option I can think of right now would be something like adding a build tag for this specifically, allowing downstream dependencies to opt-out of including that built-in function in their build. The gojsonschema lib is AFAIK a vendored dependency, and while touching that code is awkward, it looks like it could perhaps be done without major surgery. But I've only really spent a few minutes thinking about this, so it could very well be that there are issues I've not yet considered.
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.