feat (Add a check for props for all constructs) #177
Conversation
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| import * as secretsmanager from "@aws-cdk/aws-secretsmanager"; | ||
|
|
||
| export interface VerifiedProps { | ||
| dynamoTableProps?: dynamodb.TableProps, |
There was a problem hiding this comment.
Mark all the variables readonly ?
| let errorFound = false; | ||
|
|
||
| if (propsObject.dynamoTableProps && propsObject.existingTableObj) { | ||
| errorMessages += 'Cannot specify an existing DDB table AND DDB table props\n'; |
There was a problem hiding this comment.
Make the error message more user friendly by saying "Either provide existingTableObj or dynamoTableProps, not both", similar feedback for the rest of error messages
There was a problem hiding this comment.
grumble grumble...OK
| existingBucketObj?: s3.Bucket, | ||
| bucketProps?: s3.BucketProps, | ||
|
|
||
| // topicsProps is an incorrect attribute used in event-rule-sns that |
There was a problem hiding this comment.
Create an issue to track this change and make the update before we flip the switch for this pattern to stable ?
There was a problem hiding this comment.
My thought is we leave it for now, and when we rename the construct aws-eventsrule-sns in 2.0 we also fix this.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Issue #, if available: 176
Description of changes:
Currently every construct performs its own validation of inputs. This validation is usually consistent across constructs but is inconsistent across services. For instance, if you send an existing VPC and VPC Props to a construct it will throw an error, but if you send an existing Lambda function and Lambda function props to a construct then the construct will ignore the props silently.
We need to have a consistent way to check inputs that ensures consistency across constructs as well as across services. In the process we will settle on explicitly throwing an error when incompatible props are submitted (eg - props and an existing resource).
(this is internal issues T131 and T137)
Use Case
Proposed Solution
This will be accomplished with a single prop validation routine that is called at the beginning of every construct.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.