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.

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

Custom Resource Properties Keys Are Being Uppercased #7035

Closed
chriscoombs opened this issue Mar 27, 2020 · 1 comment · Fixed by #7736
Closed

Custom Resource Properties Keys Are Being Uppercased #7035

chriscoombs opened this issue Mar 27, 2020 · 1 comment · Fixed by #7736
Assignees
Labels
@aws-cdk/custom-resources Related to AWS CDK Custom Resources bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. p1

Comments

@chriscoombs
Copy link

The CustomResource type is currently uppercasing the first letter in each prop.properties key. There is no requirement in CloudFormation for the first letter to be uppercased. The CloudFormation documentation for Custom Resources shows properties with lowercase keys.

Uppercasing the properties prevents the porting of existing custom resources to CDK. Even when code changes to the backing Lambda function are possible, simple object destructuring is not.

Reproduction Steps

new cloudformation.CustomResource(this, 'Custom Resource', {
      provider: cloudformation.CustomResourceProvider.fromLambda(customResource),
      properties: {
        detail: {
          event: 'referenceCreated',
          repositoryName,
        }
      }
    })

Error Log

detail: {
          ...
        }

becomes

Detail: {
          ...
        }

Environment

  • CLI Version :
  • Framework Version:
  • OS :
  • Language :

Other

Fixed in pull request 7034.


This is 🐛 Bug Report

@chriscoombs chriscoombs added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Mar 27, 2020
@SomayaB SomayaB added the @aws-cdk/custom-resources Related to AWS CDK Custom Resources label Mar 30, 2020
@eladb eladb added the p1 label Mar 31, 2020
eladb pushed a commit that referenced this issue May 1, 2020
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 pushed a commit that referenced this issue May 1, 2020
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
Copy link
Contributor

eladb commented May 1, 2020

Superseded by #7736

@eladb eladb closed this as completed May 1, 2020
@eladb eladb reopened this May 1, 2020
@mergify mergify bot closed this as completed in #7736 May 4, 2020
mergify bot pushed a commit that referenced this issue May 4, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/custom-resources Related to AWS CDK Custom Resources bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. p1
Projects
None yet
3 participants