You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for submitting the issue! I'll start by zooming out a bit and recap cdk-chalice intent. The package is meant to automate the following approach to AWS CDK and AWS Chalice interoperability:
Create Chalice application (chalice new-project) with default "dev" stage in .chalice/config.json. CDK application could perform this Chalice application scaffolding - create new project or skip this step if project already exists in the target directory (this is chalice new-project behavior). I preferred to keep this step manual to hopefully make adoption easier for developers who already have existing Chalice projects
Create CDK application (cdk init)
Use cdk_chalice.Chalice class to generate stage per CDK stack in .chalice/config.json and run chalice package. This is the main purpose of cdk-chalice - to allow passing CDK tokens for resources such as DynamoDB table to SAM template generated by chalice package (see example here), and also to automate the packaging process itself.
Hence if AWS Chalice doesn't support accepting certain options through its configuration mechanism, there are two options I can think of - open an issue for AWS Chalice or customize the resources after they have been imported into the CDK stack by cdk-chalice. To make the latter easier, there is a tracking issue in AWS CDK for migrating CloudFormation templates to the CDK.
To clarify, once migrating CloudFormation templates to the CDK is released, I will look for integrating it into cdk-chalice itself, such that you will get CDK objects to work with for SAM template generated by chalice package.