framework-integ: we aren't testing what we are shipping

[rix0rrr]

Describe the bug

When we turned on "stripInternals": true, which broke our library for consumers, that should have been caught by the integration tests. But it wasn't. Why not?

The reason is that we aren't compiling against the PUBLIC types of aws-cdk-lib in @aws-cdk-testing/framework-integ. Instead, we are compiling against the PRIVATE TYPES.

That means that directives like "stripInternals": true and --strip-deprecated (which remove elements from the .d.ts files) haven't been applied yet. It effectively means we are testing a different API surface than the one we are shipping to customers.

The fix

The primary fix is easy. We can add the following to the config:

// @aws-cdk-testing/framework-integ/tsconfig.json
{
  // ...
  "references": [
    { "path": "../../aws-cdk-lib" }
  ]
}

Whenever we import a TypeScript file from a library, the compiler will see both the .ts and the .d.ts file. The .ts file has the source, and the .d.ts file has the public types, potentially stripped.

Without this project reference, the compiler will prefer the .ts file; with the project reference, it will prefer the .d.ts file.

So with the project reference, our integ tests will see the same API surface that our customers will.

Blockers

We can't trivially do this, because we currently have a number of integ tests for long-deprecated APIs, and they will fail to compile as soon as we consume the public API description where those types have been removed.

Needs this first:

• aws-cdk-lib: source code for many deprecated APIs still present #36342