chore(deps): full dependency update and raise cdk baseline to 2.268.0 - #83
chore(deps): full dependency update and raise cdk baseline to 2.268.0#83hoegertn wants to merge 2 commits into
Conversation
Run the projen upgrade task for managed devDeps and raise the baselines in .projenrc.ts: - aws-cdk-lib 2.168.0 -> 2.268.0 (devDep and peer floor ^2.268.0) - constructs 10.3.0 -> 10.5.0 (forced: aws-cdk-lib 2.268.0 peers constructs ^10.5.0) - jsii / jsii-rosetta ~5.7.0 -> ~5.9.0 (forced: jsii-pacmak 1.140.0 peers jsii-rosetta >=5.9.0; stays on the jsii 5.x line, no jump to 6.x major) - jsii-pacmak / jsii-diff 1.121.0 -> 1.140.0, projen 0.98.30 -> 0.103.21, prettier 3.7.4 -> 3.9.6, ts-jest 29.4.6 -> 29.4.12, eslint-plugin-prettier 5.5.4 -> 5.5.6, jest-junit 16 -> 17 - @aws-cdk/integ-tests-alpha tracks cdkVersion at 2.268.0-alpha.0; @aws-cdk/integ-runner pinned to stable 2.205.1 because its alpha channel stopped publishing at 2.185.0-alpha.0 Source fix for the CDK API change: aws-cdk-lib 2.268.0 changed FileSystemProps.kmsKey from kms.IKey to kms.IKeyRef, so read the key id via props.kmsKey?.keyRef.keyId in aws-fsx/ontap-file-system.ts.
moltar
left a comment
moltar
left a comment
There was a problem hiding this comment.
Bumping peers qualifies as a breaking change and would need to bump major.
|
Within aws-cdk-lib v2 the CDK team doesn't break stable APIs, so raising our peerDependencies floor only affects npm ≤ 6 consumers (who must hand-edit package.json) — on npm 7+ peers auto-install and a backward-compatible v2 bump breaks nothing, so I'd treat this as a non-breaking change, not a major. I want to keep the floor at the latest aws-cdk-lib (here ^2.268) deliberately, so consumers pick up the current security-patched line rather than resolving to an old one, with the same version pinned in devDependencies. We version this library on its own changes, independent of CDK's cadence, and the constructs bump stays since aws-cdk-lib transitively requires it. At least this is currently my take on versioning for other libraries. Not using latest for projects is no longer an option, in my opinion. |
3 participants
Reason for this change
Full refresh of all dependencies plus a raise of the CDK/jsii/constructs baselines, keeping the library building and all unit tests green.
Description of changes
Baseline bumps in
.projenrc.ts(regenerated withnpx projen, no hand-editing of generated files):^2.268.0)constructs ^10.5.0; 10.8.1 satisfies it. Peer floor raised to^10.8.1.npx projen upgrademoved jsii-pacmak to 1.140.0, which requires peerjsii-rosetta >=5.9.0. Stays on the jsii 5.x line (no jump to 6.x).npx projen upgrade).cdkVersionvia the template).${cdkVersion}-alpha.0template and pinned to stable2.205.1. Re-verified against the npm registry:@aws-cdk/integ-runner@2.268.0-alpha.0does not exist (404) and integ-runner's newest published version across all tags is stable2.205.1, while@aws-cdk/integ-tests-alpha@2.268.0-alpha.0does exist. This split is the only combination that resolves. It only drives the integration tests.One source change (a real fix, no casts or rule disabling):
src/aws-fsx/ontap-file-system.ts: aws-cdk-lib 2.268.0 changedFileSystemProps.kmsKeyfromkms.IKeytokms.IKeyRef, which no longer exposeskeyIddirectly. Changedprops.kmsKey?.keyId->props.kmsKey?.keyRef.keyId. The redshiftnamespace.tskeeps.keyIdbecause its own prop is typedIKey.projen 0.103 also restructured the tsconfig layout, npm scripts, and jsii config; those are regenerated output.
API.mdtracks the raised aws-cdk-lib API surface.Description of how you validated changes
npm run compile(jsii): 0 errors, 0 warnings.npm run test: 240 jest tests across 12 suites pass.npx projen eslint: exit 0, zero errors/warnings.npx projenis idempotent (no diff on re-run), confirming no generated file was hand-edited.test/aws-fsx/ontap-file-system.test.ts, which assertsKmsKeyIdin the synthesized template.Notes for maintainers
@aws-cdk/integ-runneris now pinned to2.205.1and no longer trackscdkVersion. A future CDK baseline bump must revisit this pin manually until the alpha channel resumes.package:pythonbuild step could not be verified in the sandbox: jsii-pacmak 1.140.0 needs Pythonbuild~=1.5.0but the restricted PyPI mirror caps at 1.4.4. This is a mirror limitation, not a code defect, and should pass on CI with open PyPI. Confirm it is green before cutting a release.Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license