[X-Guardian]

Related issue

Fixes #384

Description

cdktn get now removes generated resource directories that a previous run produced but the current one did not, so the output tree matches the provider version pinned in cdktf.json. Cleanup previously reconciled only the top level of providers/, leaving the per-resource directories inside a still-listed provider untouched.

How the pruning decides what to keep. TerraformProviderGenerator.emitProvider already builds a files array of everything it emitted, and derives the barrel-file exports from it. That same array now also populates a new emittedResourceFolders map, which ConstructsMaker accumulates alongside the existing versions map. ConstructsMaker.removeOrphanedResourceFolders then lists each regenerated provider folder and removes any subdirectory absent from that map.

Deriving the keep-set from the emitted files — rather than re-deriving it from the schema — means pruning cannot disagree with the barrel files: a directory is kept exactly when it is exported. To keep that guarantee explicit, the duplicated file.replace(...) path-to-directory-name logic in emitIndexFile and emitLazyIndexFile was extracted into a shared resourceFolderName helper that all three call sites now use. This is a pure refactor — the 100 existing generator snapshots are unchanged.

Scope of the deletion. Three constraints keep it conservative:

• TypeScript only. providers/<name>/<resource>/ maps one-to-one onto the emitted index exports. Other languages co-locate providers and modules in the same folders, which makes a dropped resource indistinguishable from a hand-written construct — the same reasoning removeFoldersThatShouldNotExist already applies.
• Regenerated providers only. filterAlreadyGenerated can skip a provider whose pin and folder are both unchanged. Such a provider has no emittedResourceFolders entry and is therefore never walked, so an up-to-date tree is left alone.
• Directories only. Provider-level files (index.ts, lazy-index.ts) sit alongside the resource directories and are skipped by an isDirectory() check.

It runs after save(), once CodeMaker has written the current run's files, so the walk sees the new tree and removes only what is genuinely left over. A provider folder that cannot be listed is logged at debug level and skipped rather than failing the run.

A plain cdktn get therefore converges on the same tree as cdktn get --force, without paying the cost of regenerating every provider from scratch.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[so0k]

Recommendation as posted: land #421 as-is for this issue

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.