Create a CDK style guide
- Dominant language
- TypeScript
- Stars
- 22
- Forks
- 6
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 9
Description
Opening this issue as a result of a conversation with the DevX team.
CDK is extremely versatile, which means there are several approaches to solving any given problem, each with its own advantages and disadvantages. The purpose of a style guide would be provide guidance on the recommended way to solve common problems for consistency across the library.
Ultimately, there is a clear benefit to GuCDK consumers if resources follow the same patterns, not only in terms of API, but also in terms of usability, e.g. knowing where to look in the AWS console once a resource has been created.
Benefits of having a a style guide include: steering contributors towards the right direction, lessen the burden of PR reviewers (i.e. point contributors to the style guide instead of explaining things from scratch), help avoid having the same conversations once a consensus has been reached on how to solve an issue, etc.
Some ideas on what the style guide could include:
- Recommended way to create policies (managed policies vs inline)
- Recommended way to name a resource id
- Recommended way to fix issues (i.e. introducing a breaking change vs fixing forward)
Contributor guide
Research direction
The issue names no target file, test, or entry point; begin with the referenced DevX conversation and narrow the proposed guide's scope. Define completion as a documented, agreed set of recommendations for policy creation, resource IDs, and breaking-change versus fix-forward decisions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- developer-experience, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100