Surfaced during #296 verification (see the demo-harness review comment): terraform-provider-aws PR #45464 gives provider_meta a real, documented purpose — user_agent module attribution in CloudTrail (cf. terraform-aws-modules/terraform-aws-rds#615) — and cdktn currently has no way to express it (zero references in the codebase; the addOverride escape hatch works in JSON synth but produces garbage in HCL mode — see the HCL renderer issue).
Why cdktn lacks it (verified in both engines' source, 2026-07-02)
provider_meta is a core-language construct (terraform { provider_meta "<provider>" { … } }) whose per-provider schema is returned by the plugin protocol's GetProviderSchema RPC but dropped from providers schema -json (internal/command/jsonprovider/provider.go has no ProviderMeta field, in Terraform and OpenTofu alike). RFC-04's schema-driven codegen pipeline therefore structurally cannot see it — this is a gap, not a deliberate exclusion. It is full-parity, pre-fork surface in both engines, so no targetVersions constraint is needed.
What
Phase 1 (this issue): an untyped first-class API — e.g. providerMeta on TerraformProvider or a stack-level construct — synthesizing terraform.provider_meta.<provider-local-name> = { …attrs } in JSON (and HCL once the renderer issue is fixed). Body is provider-defined; core only requires statically-evaluable attributes.
Phase 2 (optional, separate): typed per-provider ProviderMeta codegen via a raw GetProviderSchema call or vendored knowledge of popular providers' meta schemas (aws: user_agent list of { product, version, comment? }).
How (implementation notes, phase 1)
- Keyed by the provider's local name (same namespace rule as provider functions — local names change the key, aliases don't).
- JSON synth works via the existing
terraform fragment merge; HCL needs the labeled-sub-block rendering from the HCL renderer fix.
- Validation: none beyond "attributes must be static" (matches core's
JustAttributes + static-eval enforcement).
Surfaced during #296 verification (see the demo-harness review comment):
terraform-provider-awsPR #45464 givesprovider_metaa real, documented purpose —user_agentmodule attribution in CloudTrail (cf. terraform-aws-modules/terraform-aws-rds#615) — and cdktn currently has no way to express it (zero references in the codebase; theaddOverrideescape hatch works in JSON synth but produces garbage in HCL mode — see the HCL renderer issue).Why cdktn lacks it (verified in both engines' source, 2026-07-02)
provider_metais a core-language construct (terraform { provider_meta "<provider>" { … } }) whose per-provider schema is returned by the plugin protocol'sGetProviderSchemaRPC but dropped fromproviders schema -json(internal/command/jsonprovider/provider.gohas no ProviderMeta field, in Terraform and OpenTofu alike). RFC-04's schema-driven codegen pipeline therefore structurally cannot see it — this is a gap, not a deliberate exclusion. It is full-parity, pre-fork surface in both engines, so no targetVersions constraint is needed.What
Phase 1 (this issue): an untyped first-class API — e.g.
providerMetaonTerraformProvideror a stack-level construct — synthesizingterraform.provider_meta.<provider-local-name> = { …attrs }in JSON (and HCL once the renderer issue is fixed). Body is provider-defined; core only requires statically-evaluable attributes.Phase 2 (optional, separate): typed per-provider
ProviderMetacodegen via a rawGetProviderSchemacall or vendored knowledge of popular providers' meta schemas (aws:user_agentlist of{ product, version, comment? }).How (implementation notes, phase 1)
terraformfragment merge; HCL needs the labeled-sub-block rendering from the HCL renderer fix.JustAttributes+ static-eval enforcement).