-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removal of the "constructs" compatibility layer (v2.0) #192
Labels
Comments
2 tasks
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Jul 29, 2020
When a stack is created as the root of the construct tree, we now implicitly create an `App` that serves as its parent scope. The root stack is created with the ID `Default`, which ensures that `node.uniqueId` of constructs within that stack is preserved. BREAKING CHANGE: in unit tests, the `node.path` of constructs within stacks created the root of the tree via `new Stack()` will now have a prefix `Default/` which represents an implicit `App` root. Related: aws/aws-cdk-rfcs#192
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 3, 2020
When a stack is created as the root of the construct tree, we now implicitly create an `App` that serves as its parent scope. The root stack is created with the ID `Default`, which ensures that `node.uniqueId` of constructs within that stack is preserved. BREAKING CHANGE: in unit tests, the `node.path` of constructs within stacks created the root of the tree via `new Stack()` will now have a prefix `Default/` which represents an implicit `App` root. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 4, 2020
In 2.x we plan to deprecate support for the `synthesize()` and `prepare()` hooks in `Construct`. See [RFC] for motivation. This change does not remove support for these hooks, but it does remove any usage of these hooks from the AWS Construct Library. - aws-apigateway: the calculated logical ID of Deployment resources is now done through a Lazy instead of in `prepare()`. - aws-lambda: the calculated logical ID of Version resources is now done through a Lazy instead of in `prepare()`. - core: `Stack.synthesize()` is now called `_synthesizeTemplate()` and is explicitly called from `app.synth()`. - core: `TreeEtadata.synthesize()` is now called `_synthesizeTree()` and is explicitly called from `app.synth()`. The logical IDs of Lambda Version and API Gateway Deployment resources will be different after this change due to a latent bug in the previous implementation. The `prepare()` methods are called _before_ resource dependencies are resolved, which means that the hash in the logical ID did not include dependencies. Now it includes dependencies and therefore these IDs have changed. Since both of these resources are stateless, this does not introduce risk to production systems. See more details [here]. Furthermore: all calls to `ConstructNode.prepare()` were converted to `app.synth()`. Related: aws/aws-cdk-rfcs#192 [RFC]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [here]: #9410 (comment) BREAKING CHANGE: `lambda.Version` and `apigateway.Deployment` resources with auto-generated IDs will be replaced as we fixed a bug which ignored resource dependencies when generating these logical IDs. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 5, 2020
Follow up on #9410 and remove a few additional usages of `prepare`: - In the API Gateway library we leveraged `prepare()` to record dependencies between all Deployment resources and all Method resources in the APIGW. The solution is to perform two-sided bookkeeping while methods/deployments are defined and record their dependencies in-band. We also refactored the way the code in `LatestDeployment` to be slightly more readable. - In the Pipelines library prepare was replaced with an aspect (which is technically the drop-in alternative to `prepare()` in v2.0, for lack of a better solution at the moment). - In the IAM library, the `Policy` resource needs to be conditionally created only if the document contains statements. To address that, we added a new protected API to `CfnResource` which is called `shouldSynthesize()`. By default it returns `true` but if it returns `false` (in a subclass), the resource will not be rendered into the cloudformation template. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
To reduce the chance for conflicts with generated domain-specific properties in subclasses of `Construct` (see [terraform-cdk issue]), we decided that we will rename `node` to `construct`, which is less prevalent. We plan to remove the `node` API in the next major version of the AWS CDK, and therefore recommend users to migrate their code to use `construct` instead. Part of aws/aws-cdk-rfcs#192 [terraform-cdk issue]: hashicorp/terraform-cdk#230
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In [CDK 2.0], the `applyAspect` API will be removed and instead will be accessible through a "trait" pattern: Aspects.of(scope).add(aspect) Similarly, we are normalizing the tagging API to use the same pattern: Tags.of(scope).add(x, y) Tags.of(scope).remove(x) The existing APIs are still supported but marked as @deprecated. Related: aws/aws-cdk-rfcs#192 [CDK 2.0]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In [CDK 2.0] the `node.addWarning()`, `node.addError()` and `node.addInfo()` APIs will be removed in favor of a "trait" pattern: Logging.of(construct).addWarning(message) The existing APIs are still supported but marked as @deprecated. Related: aws/aws-cdk-rfcs#192 Design: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#09-logging
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In [CDK 2.0], the `applyAspect` API will be removed and instead will be accessible through a "trait" pattern: Aspects.of(scope).add(aspect) Similarly, we are normalizing the tagging API to use the same pattern: Tags.of(scope).add(x, y) Tags.of(scope).remove(x) The existing APIs are still supported but marked as @deprecated. Related: aws/aws-cdk-rfcs#192, See [Design]. [CDK 2.0]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [Design]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#02-aspects ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In 2.x we plan to deprecate support for the `synthesize()` and `prepare()` hooks in `Construct`. See [RFC] for motivation. This change does not remove support for these hooks, but it does remove any usage of these hooks from the AWS Construct Library. - aws-apigateway: the calculated logical ID of Deployment resources is now done through a Lazy instead of in `prepare()`. - aws-lambda: the calculated logical ID of Version resources is now done through a Lazy instead of in `prepare()`. - core: `Stack.synthesize()` is now called `_synthesizeTemplate()` and is explicitly called from `app.synth()`. - core: `TreeEtadata.synthesize()` is now called `_synthesizeTree()` and is explicitly called from `app.synth()`. The logical IDs of Lambda Version and API Gateway Deployment resources will be different after this change due to a latent bug in the previous implementation. The `prepare()` methods are called _before_ resource dependencies are resolved, which means that the hash in the logical ID did not include dependencies. Now it includes dependencies and therefore these IDs have changed. Since both of these resources are stateless, this does not introduce risk to production systems. See more details [here]. Furthermore: all calls to `ConstructNode.prepare()` were converted to `app.synth()`. Related: aws/aws-cdk-rfcs#192 [RFC]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [here]: #9410 (comment) BREAKING CHANGE: `lambda.Version` and `apigateway.Deployment` resources with auto-generated IDs will be replaced as we fixed a bug which ignored resource dependencies when generating these logical IDs. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
Follow up on #9410 and remove a few additional usages of `prepare`: - In the API Gateway library we leveraged `prepare()` to record dependencies between all Deployment resources and all Method resources in the APIGW. The solution is to perform two-sided bookkeeping while methods/deployments are defined and record their dependencies in-band. We also refactored the way the code in `LatestDeployment` to be slightly more readable. - In the Pipelines library prepare was replaced with an aspect (which is technically the drop-in alternative to `prepare()` in v2.0, for lack of a better solution at the moment). - In the IAM library, the `Policy` resource needs to be conditionally created only if the document contains statements. To address that, we added a new protected API to `CfnResource` which is called `shouldSynthesize()`. By default it returns `true` but if it returns `false` (in a subclass), the resource will not be rendered into the cloudformation template. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In [CDK 2.0], the `applyAspect` API will be removed and instead will be accessible through a "trait" pattern: Aspects.of(scope).add(aspect) Similarly, we are normalizing the tagging API to use the same pattern: Tags.of(scope).add(x, y) Tags.of(scope).remove(x) The existing APIs are still supported but marked as @deprecated. Related: aws/aws-cdk-rfcs#192, See [Design]. [CDK 2.0]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [Design]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#02-aspects ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 10, 2020
In [CDK 2.0] the `node.addWarning()`, `node.addError()` and `node.addInfo()` APIs will be removed in favor of a "trait" pattern: Annotations.of(construct).addWarning(message) The existing APIs are still supported but marked as `@deprecated`. Related: aws/aws-cdk-rfcs#192, See [Design]. [CDK 2.0]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [Design]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#09-logging ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
curtiseppel
pushed a commit
to curtiseppel/aws-cdk
that referenced
this issue
Aug 11, 2020
When a stack is created as the root of the construct tree, we now implicitly create an `App` that serves as its parent scope. The root stack is created with the ID `Default`, which ensures that `node.uniqueId` of constructs within that stack is preserved. BREAKING CHANGE: in unit tests, the `node.path` of constructs within stacks created the root of the tree via `new Stack()` will now have a prefix `Default/` which represents an implicit `App` root. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
curtiseppel
pushed a commit
to curtiseppel/aws-cdk
that referenced
this issue
Aug 11, 2020
In 2.x we plan to deprecate support for the `synthesize()` and `prepare()` hooks in `Construct`. See [RFC] for motivation. This change does not remove support for these hooks, but it does remove any usage of these hooks from the AWS Construct Library. - aws-apigateway: the calculated logical ID of Deployment resources is now done through a Lazy instead of in `prepare()`. - aws-lambda: the calculated logical ID of Version resources is now done through a Lazy instead of in `prepare()`. - core: `Stack.synthesize()` is now called `_synthesizeTemplate()` and is explicitly called from `app.synth()`. - core: `TreeEtadata.synthesize()` is now called `_synthesizeTree()` and is explicitly called from `app.synth()`. The logical IDs of Lambda Version and API Gateway Deployment resources will be different after this change due to a latent bug in the previous implementation. The `prepare()` methods are called _before_ resource dependencies are resolved, which means that the hash in the logical ID did not include dependencies. Now it includes dependencies and therefore these IDs have changed. Since both of these resources are stateless, this does not introduce risk to production systems. See more details [here]. Furthermore: all calls to `ConstructNode.prepare()` were converted to `app.synth()`. Related: aws/aws-cdk-rfcs#192 [RFC]: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md [here]: aws#9410 (comment) BREAKING CHANGE: `lambda.Version` and `apigateway.Deployment` resources with auto-generated IDs will be replaced as we fixed a bug which ignored resource dependencies when generating these logical IDs. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
curtiseppel
pushed a commit
to curtiseppel/aws-cdk
that referenced
this issue
Aug 11, 2020
Follow up on aws#9410 and remove a few additional usages of `prepare`: - In the API Gateway library we leveraged `prepare()` to record dependencies between all Deployment resources and all Method resources in the APIGW. The solution is to perform two-sided bookkeeping while methods/deployments are defined and record their dependencies in-band. We also refactored the way the code in `LatestDeployment` to be slightly more readable. - In the Pipelines library prepare was replaced with an aspect (which is technically the drop-in alternative to `prepare()` in v2.0, for lack of a better solution at the moment). - In the IAM library, the `Policy` resource needs to be conditionally created only if the document contains statements. To address that, we added a new protected API to `CfnResource` which is called `shouldSynthesize()`. By default it returns `true` but if it returns `false` (in a subclass), the resource will not be rendered into the cloudformation template. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 11, 2020
As a follow-up for #9557, replace all usage of the deprecated `node` API with `construct`. Related: aws/aws-cdk-rfcs#192
eladb
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 11, 2020
Introduce `Annotations.addDeprecation()` which will attach a warning to the construct indicating that a deprecated API is used. At the moment, we only use this to warn when `.node` is used instead of `.construct`, but we will gradually use this to report the usage of all deprecated APIs as a preparation for v2.0. If the environment variable `CDK_BLOCK_DEPRECATIONS` is set (and it is set in `cdk-test`), it will cause usage of deprecated APIs to throw an error instead. Related: aws/aws-cdk-rfcs#192
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 11, 2020
As a follow-up for #9557, replace all usage of the deprecated `node` API with `construct`. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot
pushed a commit
to aws/aws-cdk
that referenced
this issue
Aug 20, 2020
Introduce `Annotations.addDeprecation()` which will attach a warning to the construct indicating that a deprecated API is used. At the moment, we only use this to warn when `.node` is used instead of `.construct`, but we will gradually use this to report the usage of all deprecated APIs as a preparation for v2.0. If the environment variable `CDK_BLOCK_DEPRECATIONS` is set (and it is set in `cdk-test`), it will cause usage of deprecated APIs to throw an error instead. Related: aws/aws-cdk-rfcs#192 ---- #### Build will be failing until #9584 is merged ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is completed in the v2.0 branch of the CDK. Yeah! |
eladb
pushed a commit
to cdklabs/decdk
that referenced
this issue
Jan 18, 2022
As a follow-up for #9557, replace all usage of the deprecated `node` API with `construct`. Related: aws/aws-cdk-rfcs#192 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
As part of v2.0 we would like to deprecate the compatibility layer we have in @aws-cdk/core for the constructs library.
Progress
The text was updated successfully, but these errors were encountered: