Suggestion: implement as a projen project type

[eladb]

Hey👋!

I love this project and I was wondering if you might be interested in collaborating to implement this as a [projen] project type instead of a template.

The main downside of templating/scaffolding is that they are "single use": once a user cloned your repo and started tweaking the template, they can no longer take changes (at least not easily).

Projen takes the approach that all project files are generated from a source definition written in javascript and are read only. Changes are always made only to the source definition.

If the upstream project type changes (e.g fixes a bug or adds a feature), consumers can pick the change up and re-run projen to regenerate their project config.

You can try out projen by running:

$ npx projen new ts

And see the help.

Let me know if you would like to collaborate.

[martinpllu]

Hey eladb, great to hear from you! What a coincidence, I discovered projen a few days ago and made a note to investigate it. It looks really interesting, and as you say it could provide a clean solution for pulling in upstream changes. At the moment I'm recommending that people use forks and git merge to deal with this, but that has some challenges.

Just for my understanding, I read that "Synthesized configuration is not expected to ever be manually edited". How would that fit in with something like the ui/package.json file that might be part of the initial synthesized config but would probably be edited by the user, e.g. to add a new dependency?

[eladb]

The philosophy is that projen generates everything from your projenrc definition.

Currently dependencies are also defined in projenrc, you edit this file and run projen and your package.json gets updated.

I realize that for dependencies this is not an ideal workflow and also doesn't support things like dependabot, so I looking for a better approach.

But generally, the idea is that your project type should expose an APIs for everything your users would need.

(There is also a concept of "escape hatches" where users can patch up a certain file and escape the abstraction, but that should be last resort)

[martinpllu]

That all makes sense, thanks for explaining. I can see how an API might work for package.json dependencies - what about files containing code? For example, users might want to change the main CDK file infra/src/generic/basestack.ts in some arbitrary way. Would that require an escape hatch?

Maybe the best approach would be to create a prototype to explore this a bit!

[eladb]

That all makes sense, thanks for explaining. I can see how an API might work for package.json dependencies - what about files containing code? For example, users might want to change the main CDK file infra/src/generic/basestack.ts in some arbitrary way. Would that require an escape hatch?

Projen can also generate one-off files (like sample code to start with).

For example, if you create a typescript project through:

npx projen new ts --name foo
yarn projen

You'll notice it also generated src/index.ts and test/hello.test.ts which are not "managed by projen" (read write)

[eladb]

Yes a prototype would be awesome.

[martinpllu]

Would extending TypeScriptLibraryProject be a sensible starting point, or would it be better to extend a more generic class?

[eladb]

Yes. Exactly.

Also, we can add capabilities there and open up degrees of freedom if needed.