> That structure is likely to change during the lifetime of your software.
I don't understand this sentence. If the structure is going to change over the time, it means you will need to regenerate the whole system, plus you will apply the changes that you made on the generated code to the newest generated version. So it isn't a valid case for generating code.
* Person A [Marketer who knows html/handlebars] logs into Postmark and makes a new email template.
* Person A tells Person B [node js developer], "Please send the new 'welcome' email template from the app".
* Person B runs the cli script, so the json file now has a template with a key of 'welcome-template-2023-blue'.
* Person B can write/modify any code which calls "sendEmailTemplate" and know exactly what code is valid, wont compile, etc.
They are "generating" the "class/object/type definitions" programmatically - which seems fine to me for the code generation problem they lay out.
Which part is not "a valid case" to you?
Note: the fact that the article is "typescript + json" versus pure "typescript" doesn't seem like a important distinction with respect to it be valid code generation, not sure if others disagree.
Random note: A different way to solve this problem would be with the "cog" python module [1], but that would come with a different set of tradeoffs. :)
Maybe this is a different use case for code generators from what you have in mind? This isn't one-time upfront scaffolding, it's a recurring part of the development process.
When email templates are edited in the external service, you run the generator to pull in the latest structure, and it breaks your build with new type errors.
I don't understand this sentence. If the structure is going to change over the time, it means you will need to regenerate the whole system, plus you will apply the changes that you made on the generated code to the newest generated version. So it isn't a valid case for generating code.