Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Removal of the "constructs" compatibility layer (v2.0) #192

Closed
5 of 7 tasks
eladb opened this issue Jul 5, 2020 · 1 comment
Closed
5 of 7 tasks

Removal of the "constructs" compatibility layer (v2.0) #192

eladb opened this issue Jul 5, 2020 · 1 comment
Assignees
@eladb
Labels
management/tracking status/done Implementation complete

Comments

@eladb
Copy link
Contributor

eladb commented Jul 5, 2020 •
edited
Loading

PR Champion
#195 @RomainMuller

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

  • Tracking Issue Created
  • RFC PR Created
  • Core Team Member Assigned
  • Initial Approval / Final Comment Period
  • Ready For Implementation
    • implementation issue 1
  • Resolved
@eladb eladb changed the title Deprecation of the constructs compatibility layer (v2.0) Removal of the "constructs" compatibility layer (v2.0) Jul 5, 2020
@eladb eladb mentioned this issue Jul 9, 2020
Merged
@eladb eladb added status/review Proposal pending review/revision and removed status/proposed Newly proposed RFC labels Jul 9, 2020
@eladb eladb self-assigned this Jul 13, 2020
@eladb eladb mentioned this issue Jul 14, 2020
Closed
@eladb eladb added status/final-comment-period Pending final approval status/approved Ready for implementation and removed status/review Proposal pending review/revision status/final-comment-period Pending final approval labels Jul 20, 2020
@RomainMuller RomainMuller mentioned this issue Jul 29, 2020
Closed
2 tasks
eladb pushed a commit to aws/aws-cdk that referenced this issue Jul 29, 2020
feat(core): implicit app for root stacks
a9b059f 
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
@eladb eladb mentioned this issue Jul 29, 2020
Merged
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Aug 3, 2020
feat(core): implicit app for root stacks (#9342)
1d85a9f 
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*
@eladb eladb mentioned this issue Aug 3, 2020
Merged
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Aug 4, 2020
chore: do not use "synthesize" and "prepare" in the cdk (#9410)
e3ae645 
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 eladb mentioned this issue Aug 4, 2020
Merged
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Aug 5, 2020
chore: remove an additional "prepare" usage (#9428)
53cb749 
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
feat(core): deprecate "Construct.node" in favor of "Construct.construct"
68fbdb2 
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 eladb mentioned this issue Aug 10, 2020
Merged
eladb pushed a commit to aws/aws-cdk that referenced this issue Aug 10, 2020
feat(core): new APIs for Aspects and Tags
4bc91ef 
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 eladb mentioned this issue Aug 10, 2020
Merged
eladb pushed a commit to aws/aws-cdk that referenced this issue Aug 10, 2020
feat(core): new logging API
5c04ee7 
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
@eladb eladb mentioned this issue Aug 10, 2020
Merged
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Aug 10, 2020
feat(core): new APIs for Aspects and Tags (#9558)
a311428 
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
chore: do not use "synthesize" and "prepare" in the cdk (#9410)
4b081c7 
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
chore: remove an additional "prepare" usage (#9428)
3bef903 
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
feat(core): new APIs for Aspects and Tags (#9558)
a7a772f 
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
feat(core): new annotations api (#9563)
ae9ed62 
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
feat(core): implicit app for root stacks (aws#9342)
91ca9ac 
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
chore: do not use "synthesize" and "prepare" in the cdk (aws#9410)
8a5d7f4 
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
chore: remove an additional "prepare" usage (aws#9428)
d331d6f 
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
chore: use "construct" instead of "node" across the library
ee96018 
As a follow-up for #9557, replace all usage of the deprecated `node` API with `construct`.

Related: aws/aws-cdk-rfcs#192
@eladb eladb mentioned this issue Aug 11, 2020
Merged
eladb pushed a commit to aws/aws-cdk that referenced this issue Aug 11, 2020
feat(core): facility to warn when using deprecated apis
006954d 
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
@eladb eladb mentioned this issue Aug 11, 2020
Merged
mergify bot pushed a commit to aws/aws-cdk that referenced this issue Aug 11, 2020
chore: use "construct" instead of "node" across the library (#9584)
6a8cba4 
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
feat(core): facility to warn when deprecated APIs are used (#9585)
b1d0ac0 
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*
@nija-at nija-at added status/implementing RFC is being implemented and removed status/approved Ready for implementation labels Nov 11, 2020
@eladb eladb added status/done Implementation complete and removed status/implementing RFC is being implemented labels Feb 25, 2021
@eladb
Copy link
Contributor Author

eladb commented Feb 25, 2021

This is completed in the v2.0 branch of the CDK. Yeah!

@eladb eladb closed this as completed Feb 25, 2021
eladb pushed a commit to cdklabs/decdk that referenced this issue Jan 18, 2022
chore: use "construct" instead of "node" across the library (#9584)
1f28a31 
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
Assignees

@eladb eladb

Labels
management/tracking status/done Implementation complete
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eladb @nija-at