reamplify VS projen

My experience was very similar: I built an application using a GraphQL schema file that powered AppSync templated VTL/DynamoDB tables, as well as automatically generating GraphQL operations/types. When I cleaned up the application's template for reuse, I erroneously decided to try out Yarn 3/Lerna/PnP, and then lost an embarrassingly long time to make it work.

Each [1] tool [2] seemed [3] to break differently, and needed some form of manual massaging to make it work. That manual massaging meant learning a new configuration file syntax, multiple times.

When it worked, it felt magical. Weaving together an entire web app, powered by a small bit of GraphQL schema [4] means building at a high level of abstraction (hence can be very productive). The only issue is the muddy forest of the NPM ecosystem you're surrounded by: any step towards upgrading your external dependencies seems to cost far more time than promised.

[1] Yarn3/PnP seems to assume all packages define their dependencies correctly. Unfortunately, this isn't true in the real world. I spent hours massaging dependencies in https://github.com/ThomasRooney/reamplify/blob/master/.yarnr...

This project uses AWS CDK as infrastructure as code solution. To maintain project configuration files efficiently, the project structure is generated using projen:

I recommend visiting the github page for projen and flicking through the documentation as I won't do it justice. Projen aims to:

cdk-django uses projen for maintaining the changelog and bumping versions and publishing to npm. It is popular among developers in the CDK community and is a really awesome tool since it basically uses one file (.projenrc.ts) to configure your entire repo, including files like tsconfig.json, package.json, and even GitHub Action workflows. It has a lot of configuration options, but I'm using it in a pretty simple way. It generates a new release and items to the changelog when I manually trigger a GitHub Action.

I will give you step-by-step instructions to create your very first AWS Organization with the AWS CDK and the help of projen and cdk-organizations. You only need already an AWS Account created which is not a member or management account of another AWS Organization.

If you go down that route you should use Projen to maintain the dependencies.

An Open Source CDK Community project which I find super interesting. It is doing cherry-picking from AWS Amplify UI and AWS CDK for deployment. I do that in my private projects as well for example https://github.com/senjuns/senjuns. I think the author could enhance/simplify its repo even more by using https://github.com/projen/projen for the project setup.

That said - https://github.com/firecracker-microvm/firecracker and https://github.com/bottlerocket-os/bottlerocket are interesting, and while AWS CDK is very AWS specific, the underlying jsii https://github.com/aws/jsii and projen https://github.com/projen/projen/issues are fundamental services.

The documentation for the classes of the bundled project types is at https://github.com/projen/projen/. In this documentation, you can see that the property github includes a mergify entry, which will define if the Mergify configuration is used. The default if the github entry is not specified, is that it will be included. So in our test, we can check that this configuration is not in place, after creating a project with the mandatory parameters.