There are several types of “code gen” in relation to CUE
We should talk about these before focusing on
Configuration or data (yaml,json)
- Export: CUE -> data (cue export)
- Import: data -> CUE (cue import)
- Get Go: Go -> CUE (cue get go)
- TypeGen: CUE -> Go (… custom …)
some notes: (1) CUE only has support for importing Go right now (2) CUE only imports types from Go (3) CUE does not have functions, so we cannot represent those in CUE without a DSL
Translating CUE to
It really can’t capture all of the nuances in the vanilla form. We need to do something more complex.
The Hof Method
Some helpful links
- Discussion on Slack about the data modeling prototype in the #general channel around here: https://hofstadter-io.slack.com/archives/C013WKK9W1F/p1640891812004200
- “Adding a Datamodel” section: https://docs.hofstadter.io/first-example/data-layer/
- https://github.com/hofstadter-io/hofmod-server is based on the previous prototype of data modeling. It will be rewritten and broken into several modules
- A local code for
hofmod-gotypeare in the works.
hofmod-serverwill then build on these.
first-example is done, several production versions of the concepts therein will be made into hofmods
There are also ways to generate types without hof
- one could do essentially the same thing hof is doing in pure CUE, though less sophisticated
- If you are willing to write Go, you can walk the AST and/or cue.Value to do some things. Attributes would make this more interesting.
- hof leaves more to the data model schema + generator, so it can be more flexible without modifying the tool. This should also be composable. I plan to have an example of that in the first-example/using-a-database or maybe another section
There are also discussion and issues on CUE GitHub.
TODO, respond to