Remove validateFunctionVersions feature flag before v0.24 release (graduate to always-on)

[sakul-learning]

Context

PR #296 (function version validation) introduced the validateFunctionVersions feature flag to gate ValidateFunctionVersionSupport validation behind an opt-in context key. This validation checks that Terraform functions used through Fn.* are supported by the declared targetVersions at synth time.

The flag was intentionally behind a feature flag to avoid breaking existing projects in a minor release. New projects created via cdktn init automatically get the flag enabled through FUTURE_FLAGS.

Why now

The v0.23 → v0.24 release is a pre-v1 breaking-change-equivalent version bump. Per the feature flag lifecycle in CONTRIBUTING.md, v0.24 is the correct window to graduate the flag to always-on. If we miss this window, the flag stays gated until v0.25.

Must land BEFORE the v0.24 release is cut. Depends on PR #303.

What needs to change

1. Always register validation — terraform-stack.ts:134: remove the if (this.node.tryGetContext(VALIDATE_FUNCTION_VERSIONS)) gate, always call this.node.addValidation(new ValidateFunctionVersionSupport(this))
2. Remove from FUTURE_FLAGS — features.ts:43: drop VALIDATE_FUNCTION_VERSIONS from the FUTURE_FLAGS map
3. Stop injecting into new projects — cli-core/src/lib/init.ts: FUTURE_FLAGS iteration will naturally skip it
4. Update tests — validations.test.ts: tests that pass [VALIDATE_FUNCTION_VERSIONS]: "true" need updating; default (no-flag) behavior becomes the validated behavior
5. Update integration test config — test/typescript/function-version-validation/cdktf.json: drop the flag from context

Acceptance criteria

• ValidateFunctionVersionSupport runs on every TerraformStack regardless of context
• validateFunctionVersions is removed from FUTURE_FLAGS
• cdktn init no longer generates the flag in cdktf.json
• All tests pass with validation as the default behavior
• Tests cover both always-on validation and the no-targeted-functions path

Flagged during review of PR #296 by @so0k. /cc @jsteinich

[so0k]

PR #362 implements this.

Approach: deleted outright, no no-op shim — following this repo's one existing precedent, 3c323e76d (which graduated EXCLUDE_STACK_ID_FROM_LOGICAL_IDS and ALLOW_SEP_CHARS_IN_LOGICAL_IDS).

"Keep it accepted but ignored" turns out to already be what deletion gives us: cdktf.json's context is readonly context?: { [key: string]: any } (packages/@cdktn/commons/src/config.ts:296), passed straight through with no schema, allowlist, or unknown-key check anywhere in the CLI. An existing cdktf.json that still sets "validateFunctionVersions": "true" keeps working — the key just becomes inert. There's no hard-fail to protect against, so a shim would be dead code.

Confirmed no .jsii API diff: features.ts isn't re-exported from packages/cdktn/src/index.ts, so the constant was never part of the public/JSII surface. Your item 3 is handled automatically — init.ts iterates Object.entries(FUTURE_FLAGS) generically, so cdktn init stops emitting the key without a code change.

One consequence worth recording

Six tests in the ValidateFunctionVersionSupport block registered the validation manually on a resource, precisely because the constructor gate was off by default. With the gate always-on, every TerraformStack also registers a stack-scoped instance and both read the same stack._getUsedFunctions() — so each error gets reported twice, under [MyStack/testResource] and [MyStack].

Dropping those manual registrations makes the tests exercise the real always-on path, and the inline snapshots re-prefix to [MyStack]. The pre-existing interleaved-Apps test, which already relied on automatic registration, confirms that's the right prefix. This is why the test diff is bigger than a find/replace.

Verification

Full cdktn suite compared against untouched origin/main in a separate worktree: identical — 1 failed / 541 passed on both, the one failure being the pre-existing matchers › toPlanSuccessfully test that needs a real terraform binary.

Not verified locally: the typescript/function-version-validation integration test needs pnpm package (so mvn + dotnet), which wasn't available on the machine used. CI should cover it.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.