(cli): Merge --hotswap-fallback behavior to --hotswap CLI flag
- Dominant language
- TypeScript
- Stars
- 105
- Forks
- 122
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 71
Description
### Describe the feature
As a team of engineers, using the `cdk watch` command often, I find that people who are relatively new to CDK often make the mistake of assuming that the `cdk watch --all --hotswap --require-approval=never --concurrency=5` will "just work".
However, my teammates are often surprised when I tell them that the CLI will just "print" (with red text) when non-hotswap compatible resources are found and skip them, and carry on with other Stacks' successful deployments (because of the concurrency flag). This leads to lots of frustration and lost engineering/debugging time, wondering why a new API Gateway endpoint is not working, or whatever the skipped non-hotswappable change was.
Since I have deeper expertise with CDK, I know that the workaround is to use the `--hotswap-fallback` flag, which works intuitively - hotswap what you can, but fallback to ChangeSet based deployment. In the end, the changes are ALWAYS deployed and the end user doesn't have to care about this implementation detail.
So I was wondering would it make sense to introduce this intuitive behavior to the normal `--hotswap` flag and deprecate the poorly named and "very limited user case" (in my opinion) `--hostwap-fallback`?
### Use Case
`cdk watch --hotswap` should "just work", rather than forcing users to dig deeper and find out about the `--hotswap-fallback` flag.
### Proposed Solution
Fold `--hotswap-fallback` behavior into `--hotswap`.
### Other Information
_No response_
### Acknowledgements
- [X] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
### CDK version used
2.89.0
### Environment details (OS name and version, etc.)
MacOS
Contributor guide
Assessment
This issue has not been assessed yet.