Breaking Changes
We iterated on the namespacing for the AWS provider which got introduced in #1101. Our goal was, to enable custom L2 / L3 abstractions being built with jsii, improve the general jsii support for the namespacing and last but not least to allow both namespace and barrel imports in Typescript. A welcome side effect is a 5x performance gain when building packages via jsii for Python (from ~ 16 minutes to ~ 3 minutes) and likely other targets such as Java or C#
As a result, there are a few minor breaking changes:
DynamoDb used to be dynamo_db in Python - it's now just dynamodb)CloudwatchEventBridge namespace got renamed to eventbridgeThis was pretty much the only way to use the namespaced provider classes.
import { CloudFront } from "@cdktf/provider-aws";
new CloudFront.CloudfrontDistribution(this, "cloudfront", {});Now it's possible to either import the entire namespace, or a resource class directly.
// Similar to before, but namespace is lowercased
import { cloudfront } from "@cdktf/provider-aws";
new cloudfront.CloudfrontDistribution(this, "cloudfront", {});
// new option
import { CloudfrontDistribution } from "@cdktf/provider-aws/lib/cloudfront";
new CloudfrontDistribution(this, "cloudfront", {});See this Pull Request for more details.
Other Changes
json-schema-to-typescript #1232staticId option to TerraformOutput (uses construct id as synthesized output name)" #1213Breaking Changes
Abbreviated version below, for a guide see Upgrade Guide for 0.7
The AWS Provider has a size that makes it hard to navigate in editors, especially in languages that compile it to a single file like Python. We implemented namespaces that hold Resources and Data Sources the same category together, the categories can be found on the AWS Provider page. If you don't use the AWS provider no action is needed, if you do you need to adjust your import statements to match the namespaces. You can find more information at the upgrade guide.
When generating the provider bindings we previously translated any block to an array of a certain type, both in configuration and as properties on the resource / data source instances. For blocks that can only appear once at most this is making the API harder to use. From this version on these blocks are going to be just the type instead of an array of a certain type. For information on how to migrate please see the upgrade guide.
Technical Preview
The AWS Adapter is a technical preview and not ready for production usage. Its API is not stable and things might break unexpectedly.
The AwsTerraformAdapter (included in the @cdktf/aws-cdk package) allows you to use Amazon Web Services Cloud Development Kit (AWS CDK) constructs in your CDK for Terraform (CDKTF) projects. Find out more in the Github repository hashicorp/aws-cdk or jump straight to the documentation.
Features
Testing.synth and Testing.synthScope #1143Fixed Bugs
Refactoring
Documentation
Breaking Changes
If you use Terraform Modules you will need to adust their names. We changed the naming to be more intuitive, e.g. TerraformAwsModulesVpcAws is now Vpc. To migrate please run cdktf get with this version and change your imports to match the new abbreviated form.
Fixed Bugs
Chores
Features
Fixed Bugs
Chores
Fixed Bugs
Chores
Documentation
Testing.renderConstructTree() #1029Fixed Bugs
Breaking Changes
Abbreviated version below, for a guide see Upgrade Guide for 0.6
v3 to v10)The constructs package serves as the base for all building blocks of the CDKs (e.g. CDK for Terraform, AWS CDK and cdk8s). Recently the constructs package was lifted to v10 with a few but major changes. The reason behind those was to make it future proof and stable across different CDKs. In this process the API surface area of the constructs base package was reduced and some functionality has been moved directly to the AWS CDK instead. For more information and the underlying motivation for the changes to the constructs library refer to the Removal of Construct Compatibility Layer RFC.
Aspects are now part of cdktf as they've been removed from constructs. If you use them, you need to change your import statement to import them from the cdktf package. The api also has changed a bit. The new way to register Aspects is Aspects.of(construct).add(aspect) instead of construct.node.applyAspect(aspect).construct.node.addInfo(), construct.node.addWarning() and construct.node.addError() methods are now available under the Annotations.of(construct) API: e.g. Annotations.of(construct).addWarning('my warning'). Annotations are a part of the cdktf base library.construct.onPrepare / construct.prepare() has been removed. Instead you can use Aspects.onSynthesize has been removed. If you find yourself needing support for it, please file a new issue on this repo and describe your use-case.Features
Documentation
Fixed Bugs
Chores
Read the announcement blog post: Announcing CDK for Terraform 0.5
New Features
Documentation
Fixed Bugs
Chores
Implemented enhancements
Fixed Bugs
Breaking Changes
We're now supporting multiple Stacks! - existing Terraform state files from local Terraform workflows have to be renamed to match the stack name.
Up until CDK for Terraform version 0.2 only a single stack was supported. For local state handling, a terraform.tfstate file in the project root folder was used. With version 0.3.0 the local state file reflects the stack name it belongs to in its file name. When a terraform.tfstate file is still present in the project root folder, it has to be renamed to match the schema terraform.<stack-name>.tfstate manually.
Implemented enhancements:
Fixed Bugs
Breaking Changes
0.12. It's likely to still work for now, but it's not guaranteed anymore #592Implemented enhancements:
Fixed bugs:
Chores: