[jsteinich]

Fixes #483, #488 and #494. Supersedes #479, whose commits are all included here (see below). Independent of #484, #490 and #493.

The bug is worse than the symptom

The visible failure was a stale version in versions.json. The actual behaviour: cdktn provider upgrade in an OpenTofu project downloaded the provider from registry.terraform.io, silently ignoring the product the project targets.

readProviderSchema writes a throwaway main.tf.json and asks the CLI for the schema:

config.terraform.required_providers![target.name] = {
  version: target.version,
  source: target.source,
};

A source that names a registry pins the CLI to it. The two commands disagreed about whether the source carried a host:

• provider add passes no constraintsToGenerate, so get derives constraints from cdktf.json — the short hashicorp/random. Bare → OpenTofu uses its own registry.
• provider upgrade passed constraintsToUpdate.map((c) => new TerraformProviderConstraint(c)), built from ProviderConstraint.fromConfigEntry(provider) with no registry argument, so normalized to registry.terraform.io/hashicorp/random.

Hence one key per host in the same file, old one first, winning any lookup by provider name:

{ "registry.opentofu.org/hashicorp/random": "3.1.3",
  "registry.terraform.io/hashicorp/random": "3.2.0" }

This also explains the !explicitHostname || guard in provider-generator.ts: bare sources are the designed contract, and the upgrade path was violating it.

Three fixes

1. handlers.ts — pass namespace/name, leaving resolution to the CLI. I checked all ten new TerraformProviderConstraint(...) sites; this was the only one handing on a normalized FQPN.
2. constructs-maker.ts — updateVersionsFile no longer carries a previous entry forward for a provider regenerated this run. It matched the old entry by provider part but re-inserted it under its old fully qualified key. Defence in depth now that the host above is stable.
3. local-provider-versions.ts — a third hardcoded registry.terraform.io/ strip, found by tracing DEFAULT_HOSTNAME. This one is a reader: under OpenTofu, versionForProvider("random") returned nothing, so version detection and provider list came up empty. Now strips any public registry host.

Plus the restored OpenTofu pin, putting the matrix back to three tofu rows.

Verification

Run against both CLIs locally, each leaving a single correctly-keyed entry:

CLI	.gen/versions.json
terraform 1.14.3	{ "registry.terraform.io/hashicorp/random": "3.2.0" }
opentofu 1.12.6	{ "registry.opentofu.org/hashicorp/random": "3.2.0" }

typescript/provider-upgrade-command goes from 1 failed, 3 passed, 1 skipped to 4 passed, 1 skipped under OpenTofu, and still passes under Terraform — that path matters because this changes the source for every upgrade, not just OpenTofu ones. Of the four new LocalProviderVersions tests, the two OpenTofu cases fail against the previous implementation. @cdktn/cli-core 20 suites / 207 tests and @cdktn/provider-generator 22 tests / 10 snapshots unchanged.

Also folded in: deploy after a provider bump, and coverage for OpenTofu-targeting projects

Fixes #488 and closes #494 as well. Four more commits, from auditing what remained once the above was fixed.

cdktn deploy failed for every OpenTofu project after a provider version bump:

Could not resolve provider hashicorp/random: locked provider
registry.opentofu.org/hashicorp/random 3.6.0 does not match configured
version constraint 3.6.1; must use tofu init -upgrade

CdktfStack compares the synthesized required_providers against .terraform.lock.hcl to decide whether to run init and whether init -upgrade is needed, using exact fully-qualified addresses — and it normalized every source to registry.terraform.io. Synthesized sources are bare in practice: generated bindings copy the source as written in cdktf.json, and published prebuilt packages ship bare too (checked @cdktn/provider-aws 25.7.2). OpenTofu locks a bare source under registry.opentofu.org, so both checks missed: init ran on every deploy, and a bump never triggered init -upgrade, which the plain init then rejected. lockAddressesFor now offers every public registry for a bare source, while an explicit host still has to match exactly. Projects that fully qualify providers were never affected.

typescript/opentofu-target is the first fixture that declares an OpenTofu target. The other OpenTofu matrix rows only change which CLI runs, so nothing exercised registry resolution that follows targetVersions — which is where this whole run of defects lived. It walks get → synth → deploy → provider list → provider upgrade → redeploy, pinned to tofu1.12.6. Reverting the lock fix makes its bump step fail with the error above.

Two verification-tooling fixes, both found because they produced misleading local results:

• run-against-dist.mjs installs the CLI from its tarball instead of pnpm add cdktn-cli, which could resolve an earlier build of the same 0.0.0 version (tests: run-against-dist can install a stale CLI locally, so integration runs silently test old code #488). The glob is cdktn-cli-[0-9]*.tgz, so release builds with stamped versions still work and cdktn-cli-core-*.tgz is excluded.
• package:js|python|java|dotnet|go now depend on build. They had no target defaults, so they repacked whatever compiled output was lying around — a fresh tarball timestamp over stale contents. No CI workflow invokes them.

Matrix +1 job. @cdktn/cli-core passes; the fixture and the Terraform diff-deploy-output-destroy fixture both pass locally against tarballs extracted and checked for these changes.

Now also carries #479, plus review fixes

#479 is folded in and closed. On its own it regressed provider upgrade in OpenTofu-only projects: it moved CdktfConfigManager onto the project's registry while the upgrade handler still normalized against Terraform, so an installed provider looked missing. The handler fix and the regression test both live here, so the two now land together.

Fixes from review:

• Lock matching (revised after a second review). An earlier fix here made a bare source match only the running CLI's registry, identified with terraform version before every init. That was reverted (b668906). init always runs, so nothing was ever skipped, and OpenTofu migrates a Terraform lock entry on its own. The filter broke the realistic case: after deploying with Terraform, a provider bump under OpenTofu got no -upgrade and tofu init failed, as reproduced with Terraform 1.14.3 and OpenTofu 1.12.6. It also leaked terraform version output into every diff/deploy/destroy log. A bare source now matches its lock entry under either public registry; an explicit host still matches only itself. The decisions stay in needsLockfileUpdate / needsUpgrade, and the tests cover the Terraform→OpenTofu bump.
• provider upgrade keeps explicitly named hosts. Schema generation had dropped every host. ProviderConstraint.requiredProvidersSource keeps a public or private host the user wrote and drops only one added by normalization. Writing the upgraded entry back to cdktf.json had the same problem, found by sakul-learning's scenario runner (368efb3): an update now keeps the entry's own spelling of its source and changes only the version.
• Matrix comment for the provider-command OpenTofu pins now says they exercise the CLI, not a project that targets OpenTofu.

Each new test was mutation-checked against the reviewed behaviour. Locally, against tarballs checked for these changes: opentofu-target passes 6/6 under tofu 1.12.6, diff-deploy-output-destroy passes 5/5 under Terraform, and cli-core passes with lint clean.

Worth knowing about the verification

Two earlier "verification" runs of this fix were invalid, and both looked like real failures:

• nx run-many -t package reported success while serving a two-week-old cached cdktn-cli tgz.
• After rebuilding with --skip-nx-cache, run-against-dist.mjs still installed an older CLI, because it does pnpm add cdktn-cli and the version is permanently 0.0.0.

Filed as #488 with a fix. Anyone reproducing this locally should confirm the installed CLI contains their change — and grep the shipped *.js.map, since esbuild strips comments and minifies the bundle.

Release notes

• Behaviour change: in a project whose targetVersions declares only OpenTofu, provider add / provider upgrade write providers to cdktf.json in the short form (hashicorp/random) rather than with registry.terraform.io/. An existing entry keeps the host it was written with.
• Behaviour change: the lock-file checks before init match a bare provider source against a lock entry from either public registry. A provider bump after switching between Terraform and OpenTofu now runs init -upgrade.
• Known limitation (OpenTofu 1.12 and later, not caused by this PR): a provider whose source names registry.terraform.io explicitly fails to deploy under OpenTofu. tofu providers lock adds a second, hash-less registry.opentofu.org entry, and apply then fails with there is no package for registry.opentofu.org/... cached in .terraform/providers. Plain HCL fails the same way (tofu init, tofu providers lock -platform=linux_amd64, tofu apply); OpenTofu 1.8.2 and 1.9.3 work. Workaround: use the bare hashicorp/x source, or run tofu init again in the stack directory.
• Follow-up: provider upgrade: keep an explicit provider host in the generated binding and in object-form entries #532 (an explicit host is still dropped from the regenerated binding and from object-form entries on upgrade).

🤖 Generated with Claude Code

[so0k]

terraform version output now shows up in every diff / deploy / destroy

Finding. After a79880b, every Terraform user sees the CLI's version text in their stack log on each diff, deploy and destroy, once per stack. That includes Your version of Terraform is out of date! and, once providers are installed, the + provider … lines.

Cause. CdktfStack.initalizeTerraform now calls runningCliRegistry() unconditionally, and that calls TerraformCli.version().

cdk-terrain/packages/@cdktn/cli-core/src/lib/models/terraform-cli.ts

Lines 469 to 483 in 13e03aa

	public async version(): Promise<string> {
	try {
	return await exec(
	terraformBinaryName,
	["version"],
	{
	cwd: this.workdir,
	env: process.env,
	signal: this.abortSignal,
	noColor: true,
	},
	this.onStdout("version"),
	this.onStderr("version"),
	);
	} catch {

version() passes this.onStdout("version") to exec, which is the stack's log handler, so the output reaches onLog and the UI.

On main this only ran behind validateInstalledBinary: true, because validateInstalledBinaryIfConfigured returns early without it.

So for most projects this is a new process spawn per stack init as well as new output.

The other version probes, commons terraformCli() and provider-schema's getFetchingCliVersion(), are cached per process and stay out of the log.

Does the lock check need to know the running CLI?

a79880b justified identifying the running CLI with two switching cases. I ran both directions with plain HCL using the same init invocations cdktn would issue:

• Terraform 1.7.5 and OpenTofu 1.12.6,
• a shared plugin cache,
• hashicorp/random,
• one stack directory deployed by one CLI and then run by the other.

Scenario	Lock before	cdktn's init with 72da894 (any public registry)	cdktn's init with a79880b (running CLI only)
Terraform → OpenTofu, no bump	registry.terraform.io 3.6.0	tofu init ✅ OpenTofu rewrites the lock entry to registry.opentofu.org itself ("Dependency lock file entries automatically updated… version selections were preserved"), apply is a no-op	tofu init + providers lock ✅
Terraform → OpenTofu, bump to 3.6.1	registry.terraform.io 3.6.0	tofu init -upgrade ✅	plain tofu init ❌ Could not resolve provider hashicorp/random: locked provider … must use tofu init -upgrade
OpenTofu → Terraform, no bump	registry.opentofu.org 3.6.0	terraform init ✅ keeps both entries (OpenTofu state references its own provider), apply is a no-op	not run
OpenTofu → Terraform, bump	registry.opentofu.org 3.6.0	terraform init -upgrade ✅	not run

• Case 1 in the commit message ("counted as locked, init was skipped, and OpenTofu then failed on the lock file"): init always runs. The lock checks only add -upgrade and the follow-up providers lock -platform=linux_amd64. OpenTofu migrates the Terraform entry on its own, so nothing fails.
• The bump after a switch fails because of the running-CLI filter. a79880b ignores the other registry's entry, so no -upgrade is added and OpenTofu rejects the plain init. 72da894 handles it.
• Case 2 (a stale entry for the inactive registry forcing an unneeded -upgrade) is real, but only after a switch, and it costs one extra -upgrade.

Switching binaries over the same .terraform and lock file is awkward in plain HCL too, so I'd rather not add per-init CLI detection to work around it.

Suggested fix

One commit on this branch: revert the running-CLI part of a79880b and keep its tests.

• Remove runningCliRegistry() and the cliRegistry parameter. A bare source matches its lock entry under any public registry, as in 72da894. A source that names a host still matches exactly.
• Keep needsLockfileUpdate / needsUpgrade as the exported functions production calls, with their tests minus the cliRegistry cases, including the lock that holds both registries.
• Make lockAddressesFor module-private and drop its describe block, since the two decision functions already cover it.

This removes the log output and the extra spawn. It also removes the forced providers lock on every init when the CLI can't be identified (e.g. a wrapper set as TERRAFORM_BINARY_NAME).

Follow-up, not this PR: warning when the declared target and the running binary disagree belongs in the opt-in validateInstalledBinary check, ideally once per command from the cached commons terraformCli() probe rather than per stack.

Happy to push that commit here if that works for you.

[jsteinich]

Thanks for running the switch cases. You're right on every point, and I reproduced the decisive one with Terraform 1.14.3 and OpenTofu 1.12.6: after a Terraform deploy, bumping 3.6.0 → 3.6.1 under OpenTofu gets no -upgrade with the running-CLI filter, and tofu init fails with "must use tofu init -upgrade". Matching either registry upgrades cleanly. My first justification was also simply wrong: init always runs, so nothing was ever skipped.

I've pushed the change you outlined as b668906. It reverts the running-CLI detection, so there's no extra version spawn and nothing extra in the stack log. needsLockfileUpdate / needsUpgrade stay as the functions production calls, and their tests now cover the Terraform→OpenTofu bump; filtering bare sources to one registry fails three of them. lockAddressesFor is module-private. Agreed that a declared-target vs running-binary warning belongs in the opt-in validateInstalledBinary check, using the cached commons probe; happy to take that as a follow-up.

[sakul-learning]

Empirical repro (cdktn-cli@next 0.25.0-pre.60): provider upgrade random@=3.6.1 in an OpenTofu-targeted project leaves stale OpenTofu 3.6.0 + new Terraform 3.6.1 entries in .gen/versions.json.
b668906d4 keeps one OpenTofu 3.6.1 entry, reports the provider version, and redeploys; Terraform→OpenTofu + bump also fails on @next and passes on the branch.

Two follow-ups:

• shorthand upgrade drops an explicitly configured OpenTofu hostname;
• OpenTofu deployment of an explicitly Terraform-hosted provider fails after lock refresh.

Repro setup and scenario runner: https://github.com/sakul-learning/cdktn-provider-registry-scenarios

[so0k]

Independent rerun of the scenario runner against cdktn-cli@0.25.0-pre.60, b668906 and 368efb3 (Terraform 1.7.5, OpenTofu 1.12.6):

Scenario	pre.60	b668906	368efb3
OpenTofu target, bare source, upgrade to 3.6.1	❌ stale OpenTofu 3.6.0 + Terraform 3.6.1 in versions.json	✅	✅
Terraform → OpenTofu, bump	❌ redeploy fails	✅	✅
OpenTofu → Terraform, bump	❌ stale entry kept	✅	✅
Explicit registry.opentofu.org, shorthand upgrade	❌ "not installed"	❌ host dropped from cdktf.json	✅ cdktf.json keeps the host
Explicit registry.terraform.io under OpenTofu	❌	❌	❌

• Explicit host on upgrade: fixed in cdktf.json by 368efb3. The regenerated binding still uses the argument's bare source until the next cdktn get, and object-form entries still lose the host. This is low impact and tracked in provider upgrade: keep an explicit provider host in the generated binding and in object-form entries #532.
• Explicit registry.terraform.io under OpenTofu: OpenTofu behaviour, not a cdktn defect. Plain HCL fails the same way on OpenTofu 1.12.3, 1.12.6 and 1.13.2 (tofu providers lock adds a hash-less registry.opentofu.org entry); 1.8.2 and 1.9.3 work. Documented under Release notes in the PR body.

Rebased onto main (no changes to the PR commits) and set to auto-merge.