go-to-k
commented
2 weeks ago Our contributing guide says that Focus on only accepting L2 constructs to start. L3 constructs will come later as the library matures.. I take it that L2, which is not in the aws-cdk now, is accepted as a priority, and L3 is also accepted, but with a lower priority. (Or it may have the potential to leave all L3s alone now.)
It would be good to discuss edge cases on a case-by-case basis. However, I personally feel that the edge cases, which are difficult to determine, would be treated the same as L3. Probably because they are less likely to be accepted by the aws-cdk than L2.
hoegertn
What kind of constructs do we want to have in here? What's the main focus that we actively try to get in, which ones do we accept and maintain but would not proactively add ourselves?
Ideally we can first align on the rough direction here, and I'm happy to create an ADR out of this. My impression is that there is overall alignment to focus on "L2s that would have been accepted in to aws-cdk in the past, but now no longer will", but there are edge cases which are not super clear from this definition. Also, we did discuss to potentially have L3 constructs in here as well.
We have some implicit assumptions around this in our ADR to folder structure which mentions L3 constructs like
static-websiteand helpers liketypescript-asset, but we never explicitly discussed whether these should actually part of this library.A concrete example for this is the discussion around in-project lambdas or TypeScript assets in #8. We also started part of this discussion in #13.