Lint generated provider bindings with ESLint to catch ESM/Node type-stripping incompatibilities

[sakul-learning]

Background

The provider-generator (packages/@cdktn/provider-generator) outputs TypeScript bindings consumed as real source code by downstream projects. When the demo harness was moved to ESM with Node native type-stripping (--experimental-strip-types), three defects surfaced that were invisible to the existing test suite (snapshot tests + jsii compilation):

1. Missing /index in ESM imports — nodenext resolution looks for ../provider-functions.js, not ../provider-functions/index.js
2. TypeScript parameter properties — constructor(private readonly x: T) is NOT pure type erasure; the compiler synthesizes an assignment, so Node type-stripping throws ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX
3. T[] binding ambiguity with union types — boolean | cdktn.IResolvable[] binds differently from Array<boolean | cdktn.IResolvable>

All three were fixed in #296, but they were only caught by exercising the generated code manually — not by any automated linting.

Problem

Generated code is never linted. The repo has ESLint flat configs, but generated output in providers/<provider>/ is never pointed at them. Patterns that are valid TypeScript but incompatible with Node type-stripping, ESM resolution, or modern best practices can ship in generated code without detection.

Proposed Solution

Add a linting step to the provider-generator test/CI pipeline that runs ESLint over generated output with a targeted ruleset.

Suggested ESLint rules

Rule	What it catches
import/no-unresolved	Broken ESM import paths (would have caught the missing /index)
import/extensions	Missing .js extensions in ESM-relative imports
@typescript-eslint/consistent-type-imports	Imports that should be import type (ensures type-stripper erasability)
@typescript-eslint/no-explicit-any	any types in generated signatures (force deliberate usage)
@typescript-eslint/no-unused-vars	Unused imports or unreferenced constructor params
no-duplicate-imports	Duplicate imports in generated struct shards

Integration considerations

• Disable formatting rules (prettier/prettier) — formatting is the generator's job
• Disable @nx/enforce-module-boundaries — generated code has no Nx project context
• The generator uses import * as cdktn from 'cdktn' namespace imports — may need inline disable or rule override for no-unused-vars
• any types are intentional for unknown Terraform provider shapes, but lint enforcement forces deliberate // eslint-disable-next-line usage

Related

• PR feat: support newer provider plugin-protocol features via targetVersions (RFC-04) #296 — fixes the three defects described above
• provider-functions-emitter.ts:40-46 — the parameter-property avoidance comment

Flagged during review of PR #296 by @so0k.

[jsteinich]

Folding in #351, which I'm closing as a duplicate of this issue — same ask, filed a week apart.

The framing worth keeping from it: scope the rule selection around erasable-syntax-only checks specifically, since that's the class of defect that actually made it downstream (parameter properties throwing ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX under Node type-stripping), rather than a general lint pass over generated output.