feat: remove the construct compatibility layer #12054
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
December 13, 2020 14:59
1. construct-compat.ts deleted 2. update core code & tests 3. update awslint 4. update pkglint
|
|
eladb
changed the title
nija-at
previously requested changes
Dec 18, 2020
There was a problem hiding this comment.
I'm terribly worried about merge conflicts here.
How about we first change all these files on master to look like -
import ...
import * as cdk from '@aws-cdk/core'
import ...
import { Construct } from '@aws-cdk/core';We have our own linter now that we can use to enforce this. I'm happy to help with the linter rule.
When the change to v2-main occurs, it's just a change to the import statement. Since it's separate from the rest of the imports, git can better resolve these changes.
I don't think 3 deleted lines are going to be a problem, but I will make sure to monitor the merges after this is merged to v2 and see what we can do to make sure we have no conflicts from this change. If it means to restore these lines, I'll do it. |
added 7 commits
December 24, 2020 14:47
…-construct-compat
…-construct-compat
eladb
added
the
pr-linter/exempt-readme
eladb
added
the
pr-linter/exempt-test
eladb
changed the title
rix0rrr
changed the title
rix0rrr
reviewed
Jan 4, 2021
rix0rrr
approved these changes
Jan 5, 2021
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). |
skinny85
added a commit
to skinny85/aws-cdk
that referenced
this pull request
Jan 19, 2021
The monocdk packages in the V2 branch were [recently switched](aws#12054) to using constructs in version 10.0.0-pre.5. However, our e2e-tests always [install the latest constructs](https://github.com/aws/aws-cdk/blob/12868a2ac9c7016e47633045fb0c00be7eeb5092/packages/aws-cdk/test/integ/helpers/cdk.ts#L124), which is 3.2.108 currently, as pre-release versions are not considered when installing the latest (and if they were, that would break the tests on the 'master' branch anyway). Make the version of 'constructs' used configurable through an environment variable. We will then need to update the tests in the v2 branch to set that to 10.0.0-pre.5.
foriequal0
reviewed
Mar 5, 2021
eladb
pushed a commit
that referenced
this pull request
Mar 30, 2021
Delete bunch of remaining APIs that are deprecated and available in constructs 10.x Follow up of #12054
mergify bot
pushed a commit
that referenced
this pull request
Apr 6, 2021
Delete bunch of remaining APIs that are deprecated and available in constructs 10.x Follow up of #12054 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
njlynch
added a commit
that referenced
this pull request
Sep 21, 2021
When the constructs compatibility layer was removed on the v2 branch (#12054), a change was made to the init templates to support a flexible constructs version (either ^3 or ^10). These changes were never back-ported to v1, leading to the situation where there are (unnecessary) differences on the v2 templates between the v1 and v2 branches. Backported these changes manually (for package.json and init.ts), and then by diffing the init templates directory between master and v2-main.
mergify bot
pushed a commit
that referenced
this pull request
Sep 21, 2021
) When the constructs compatibility layer was removed on the v2 branch (#12054), a change was made to the init templates to support a flexible constructs version (either ^3 or ^10). These changes were never back-ported to v1, leading to the situation where there are (unnecessary) differences on the v2 templates between the v1 and v2 branches. Backported these changes manually (for package.json and init.ts), and then by diffing the init templates directory between master and v2-main. ---- *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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After we extracted the constructs programming model into the
constructsmodule, in order to maintain backwards compatibility in the v1.x release line, we had to include a compatibility layer between the AWS CDK and constructs.One of the goals of 2.0 was to remove this redundant layer and directly use
constructs.Constructswithin the AWS CDK.This RFC describes this activity in detail.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license