feat(core): move all types from "aws-cloudformation" to "core" #7736
Conversation
Fold the "assets" module, which includes the Staging construct that takes care of staging asset files into the cloud assembly during synthesis into "core". This is in order to allow implementing custom resources that leverage assets throughout the framework. A subsequent commit will add a mini-framework for custom resources that leverages this capability.
This commit folds the `CustomResource` and `NestedStack` types from `@aws-cdk/aws-cloudformation` into `@aws-cdk/core` in order to allow code in `core` and other lower layers to use capabilities such as nested stacks and custom resources. This comes at a minor sacrifice to API fidelity: the provider's service token is for custom resources is now passed as a simple `string` instead of a strongly typed `ICustomResourceProvider`. But this is negligible for this type of resource given the high involvement users require to use it anyway. Additionally, the `NestedStack` class accepts a `notificationArns` as a `string[]` instead of an `sns.ITopic[]`. In both cases the API in `@aws-cdk/aws-cloudformation` (which is considered a stable module) remains unchanged with a compatibility layer added. We took this opportunity to change the behavior of custom resources so that it won't pascal-case property names by default. This resolves #4896 and resolves #7035 and supersedes #7034. The API in the aws-cloudformation module are still supported for backwards compatibility but marked as deprecated.
eladb
changed the title
eladb
changed the title
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 |
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 |
We have `true` in the compatibility layer
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 |
| * serviceToken: myTopic.topicArn | ||
| * ``` | ||
| */ | ||
| readonly serviceToken: string; |
There was a problem hiding this comment.
Make this an IServiceToken or something with a single string attribute?
We can still have it typed, even if the dependency goes the other way. We can have class Function implements IServiceToken, for example.
There was a problem hiding this comment.
This will "pollute" the public APIs of lambda.Function and sns.Topic in an unwanted way, and I don't think this is warranted for this use case. The documentation is clear and easy enough to follow and we expect people who implement custom resources to be able to easily follow it.
There was a problem hiding this comment.
If you think it's polluting Function then we could easily have migrated the ResourceProvider as well.
But fine, strings it is.
There was a problem hiding this comment.
If you think it's polluting Function then we could easily have migrated the ResourceProvider as well.
How? ResourceProvider.fromLambda references a IFunction which does not exist in core.
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 |
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). |
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). |
Commit Message
feat(core): move all types from "aws-cloudformation" to "core" (#7736)
This commit folds the
CustomResourceandNestedStacktypes from@aws-cdk/aws-cloudformationinto@aws-cdk/corein order to allow code incoreand other lower layers to use capabilities such as nested stacks and custom resources.This comes at a minor sacrifice to API fidelity: the provider's service token is for custom resources is now passed as a simple
stringinstead of a strongly typedICustomResourceProvider. But this is negligible for this type of resource given the high involvement users require to use it anyway. Additionally, theNestedStackclass accepts anotificationArnsas astring[]instead of ansns.ITopic[]. In both cases the API in@aws-cdk/aws-cloudformation(which is considered a stable module) remains unchanged with a compatibility layer added.We took this opportunity to change the behavior of custom resources so that it won't pascal-case property names by default. This resolves #4896 and resolves #7035 and supersedes #7034.
The API in the aws-cloudformation module are still supported for backwards compatibility but marked as deprecated.
End Commit Message
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license