fix(aws-kinesisfirehose-s3): Fix type of kinesisFirehoseProps prop.

[ScottRobinson03]

In V1.64.0 the type of the kinesisFirehoseProps prop was adjusted from kinesisfirehose.CfnDeliveryStreamProps to kinesisfirehose.CfnDeliveryStreamProps | any. I assume this was to prevent a type error around bucketArn and roleArn being required in kinesisfirehose.CfnDeliveryStreamProps, but not within the prop (since the construct handles setting these).

This was a lazy solution that meant developers haven't been able to benefit from the autocompletion of the type. The type has been corrected in this PR so that people can get autocomplete on the properties again.

The type admittedly isn't the prettiest, but does work and is the best way I could find to achieve the correct type.

I'm not sure why there's a | cdk.IResolvable; on the type originally, but I kept it here just in case.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[aws-solutions-constructs-team]

AWS CodeBuild CI Report

• CodeBuild project: githubautobuild-for-cdk-v2
• Commit ID: 0a8a637
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[ScottRobinson03]

Looks like there's something wrong with the build steps so the CodeBuild is failing... 🤔

[biffgaut]

Thanks! Unfortunately, the issue here is that Solutions Constructs uses JSII to publish the libraries for Java and Python projects (the same library used by CDK to support multiple clients). The benefit of this is being able to serve more clients, but the drawback is that this imposes limitations in how we manipulate types in Typescript. We want to allow users to specify any subset of properties on incoming props without having to fill in all required properties (which we will supply as defaults), hence our use of any. Ideally, we'd use Partial<> for this but JSII can't translate this to other languages.

In this case, the build is working fine - but our build step is jsii rather than tsc. The first error that occurs in the log is:

@aws-solutions-constructs/aws-kinesisfirehose-s3: lib/index.ts:52:12 - error JSII1001: Non-primitive types without a symbol cannot be processed.

Which indicates to me that JSII cannot not process the omit utility type. That's disappointing, as we had not considered it previously and it was an intriguing possibility. If you check out the jsii repo, you can see that people have raised issues around Partial<>, and one of the team members explains the issue to some extent here.

[ScottRobinson03]

@biffgaut

Thanks! Unfortunately, the issue here is that Solutions Constructs uses JSII to publish the libraries for Java and Python projects (the same library used by CDK to support multiple clients). The benefit of this is being able to serve more clients, but the drawback is that this imposes limitations in how we manipulate types in Typescript. We want to allow users to specify any subset of properties on incoming props without having to fill in all required properties (which we will supply as defaults), hence our use of any. Ideally, we'd use Partial<> for this but JSII can't translate this to other languages.

In this case, the build is working fine - but our build step is jsii rather than tsc. The first error that occurs in the log is:

@aws-solutions-constructs/aws-kinesisfirehose-s3: lib/index.ts:52:12 - error JSII1001: Non-primitive types without a symbol cannot be processed.

Which indicates to me that JSII cannot not process the omit utility type. That's disappointing, as we had not considered it previously and it was an intriguing possibility. If you check out the jsii repo, you can see that people have raised issues around Partial<>, and one of the team members explains the issue to some extent here.

Hmm, interesting, I see. Thanks for the response.

After doing a little bit of research I came across aws/jsii#1707, which suggests using jsii-struct-builder to add support for utility types such as Omit. Is this something that has been looked into before?