fix(provider-generator): satisfy module provider configuration aliases on get

[jsteinich]

Fixes #379

cdktn get fetches a module schema by writing a synthetic root config that calls the module and running terraform get in it. A module declaring configuration_aliases in its required_providers makes that root config invalid — Terraform demands the caller pass those configurations in — and terraform get used to downgrade the resulting error to a warning and write the module manifest anyway, which is what the fetch relied on.

Terraform 1.15 routed init and get through the graph-based install workflow (hashicorp/terraform#38217), which never reaches that downgrade (installErrsOnly no longer has any effect for get) and returns before writing the manifest. From 1.15.7 on, cdktn get therefore fails with "Missing required provider configuration" for any such module, and .terraform/modules/modules.json is never written, so the failure cannot simply be tolerated. OpenTofu still has the downgrade in both of its install paths and is unaffected.

Approach

Read what the module actually declares rather than guessing up front or parsing the error text:

1. The first terraform get is treated as a fetch whose diagnostics are deferred. Terraform installs the module either way — it just skips the manifest.
2. The module's own required_providers block (parsed with the hcl2json call the harvest step already makes) says which aliased configurations are required.
3. Those are declared in the root config and passed to the module call, and a second terraform get produces the manifest.

Modules without configuration_aliases are unaffected, and a fetch that fails for any other reason still reports its original error.

Alternatives considered and rejected: parsing alias names out of the error prose (English-prose-dependent); reading them from the Terraform Registry API before fetching (provider_dependencies does not expose configuration_aliases, and it would not cover git or local sources); terraform init -from-module (skips validation entirely but takes no version argument, so registry modules cannot be pinned); version-gating on Terraform >= 1.15 (no benefit — the declaration-driven flow is version-agnostic and also silences the pre-1.15 warning).

exec gains a logStderrAsDebug option so the deferred fetch does not print an [ERROR] block that a following success contradicts. When the fetch turns out not to be salvageable, the held-back diagnostics are re-logged at error level before rethrowing, so that output is unchanged.

Testing

• New local-module-provider-aliases fixture and snapshot test, a test that a genuinely unfetchable module still fails loudly, and unit tests for the new helpers.
• Full @cdktn/provider-schema suite passes against both Terraform 1.14.3 (which only warned) and 1.15.8 (which errors); the same suite fails on 1.15.8 without this change.

🤖 Generated with Claude Code

[sakul-learning]

There is still a .tf.json gap in the cdktn get module-schema path at PR head d20d476ec1f21379dd7f72c5fd2a3a201f562be7: for a child module declaring configuration_aliases = [null.extra] (JSON equivalent: "configuration_aliases": ["null.extra"]), cdktn get succeeds for native HCL but, with .tf.json, Terraform 1.15.8 fails with Missing required provider configuration for null.extra. In practice, this prevents consumers of JSON-syntax modules that require an aliased provider configuration from running get successfully on Terraform 1.15.8.

CLI	Module syntax	Terraform 1.14.3	Terraform 1.15.8
[email protected]	HCL	✅	❌
[email protected]	JSON	✅	❌
PR head d20d476	HCL	✅	✅
PR head d20d476	JSON	✅	❌

The matrix shows that [email protected] supports both syntaxes on Terraform 1.14.3; this PR restores the Terraform 1.15.8 behavior for HCL only.

I published the credential-free reproduction harness here:
https://github.com/sakul-learning/cdktn-provider-alias-repro

It pins Node, pnpm, Go, Terraform 1.14.3, and Terraform 1.15.8 with mise. make prepare-pr checks out and builds this exact PR commit, while make verify-findings runs all eight cells and verifies that expected failures contain the provider-configuration diagnostic rather than an unrelated setup error.

Would you prefer to include .tf.json alias handling and regression coverage in this PR, or track it as a follow-up? This is a scope decision for the PR author; the reproduction harness can also test a newer local checkout with CDKTN_REPO=/path/to/cdk-terrain make pr-matrix.

[so0k]

If you believe the fix for json should be a separate PR - then let me know and I'm ok with that - but maybe we could fix both in the same PR (unless it blows up the linecount)