feat(core): the "constructs" module#6623
Conversation
This commit extracts the constructs programming model into an independent library called `constructs`. This library includes the Construct base class (and satellites) as well as the token system. The main motivation is to enable projects like [CDK for Kubernetes] to reuse these building blocks and allow interoperability between the frameworks (hence they have to use the same base types). To ensure backwards compatibility until we release v2.0 of the AWS CDK, the `constructs-compat.ts` file implements shadow and wrapper types for types that are now in "constructs" so the AWS CDK code remains unchanged and fully passes API compatibility tests. The token system and a bunch of types related to dependencies has been _duplicated_ since the effort of shadowing was too great and there is no major value (it would still be possible to interoperate even if we have two token systems). [CDK for Kubernetes]: https://github.com/awslabs/cdk8s
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
otherwise, we will have to change all import statements and I want to avoid unnecessary diffs.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Since we rely on peer dependencies it's not needed any longer and also conflicts with the one we already have in @aws-cdk/core, so it's a good opportunity to get rid of it.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
rix0rrr
left a comment
There was a problem hiding this comment.
Okay this thing is cray-cray to review :)
I imagine synthesis is part of the constructs library as well; what about the cx-api protocol and all the CloudFormation-specific artifacts in there?
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| eval: e => { | ||
| for (const method of e.ctx.directEventMethods.concat(e.ctx.cloudTrailEventMethods)) { | ||
| e.assert(!e.ctx.interfaceType || e.ctx.interfaceType.allMethods.some(m => m.name === method.name), `${e.ctx.fqn}.${method.name}`); | ||
| e.assert(!e.ctx.interfaceType || e.ctx.interfaceType.allMethods.filter(m => !m.protected).some(m => m.name === method.name), `${e.ctx.fqn}.${method.name}`); |
There was a problem hiding this comment.
@rix0rrr This is needed because the protected lifecycle methods in constructs.Construct are named onSynthesize, onValidate and onPrepare.
There was a problem hiding this comment.
Not forcing protected methods to be part of a public interface would always have been the right thing to do anyway, regardless of the change you just made.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| cd $(mktemp -d) | ||
| npm init -y | ||
| npm install ${tarball} | ||
| npm install ${tarball} constructs@${constructs_version} |
There was a problem hiding this comment.
Doesn't this run into bootstrapping problems? Is the construct library already published to NPM at the right version here? What IS the versioning strategy for that even?
There was a problem hiding this comment.
The versioning strategy is that it has it's own semantic version line. Current version is 1.1.2
Wait, the proposed new "constructs" library is not in this PR anymore, is it? |
|
Oh one more thing: how does the Assembly fit into this? I guess CXAPI is not a dependency of |
@rix0rrr I changed the interface of |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Core review pointers:
TODO:
constructs(Request for PyPI name transfer harlowja/constructs#1).Constructs, packageId:Constructs).software.constructs, package:constructs)Commit Message
feat(core): the "constructs" module (#6623)
This commit extracts the constructs programming model into an independent library called
constructs(npm, Maven, PyPI, NuGet). This library includes theConstructbase class (and satellites) as well as the token system. The main motivation is to enable projects like CDK for Kubernetes to reuse these building blocks and allow interoperability between the frameworks (hence they have to use the same base types).To ensure backwards compatibility until we release v2.0 of the AWS CDK, the
construct-compat.tsfile implements shadow and wrapper types for types that are now in "constructs" so the AWS CDK code remains unchanged and fully passes API compatibility tests.The token system and a bunch of types related to dependencies has been duplicated since the effort of shadowing was too great and there is no major value (it would still be possible to interoperate even if we have two token systems).
Added an additional dependency on
constructsto all AWS CDK modules.MONOCDK: has been modified to take a
peerDependencyon this new module as this will be the final setup (users will have to depend on bothmonocdkandconstructs), so we are not going to take shortcuts here.TESTING: All relevant unit tests were duplicated from @aws-cdk/core to constructs, and intentionally maintained unchanged in core to ensure backwards compatibility.
End Commit Message
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license