-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Improvements to code generation templates #1385
Comments
All great ideas. A few comments:
|
@milesj great to hear there are! I see moon as the tool that will be always there, so the greater its template support the better! 🥳 |
Landing some of this here: #1398 |
Looks like I forgot to actually send the detailed response:
For sorting, yes. But if you ever want to support prompt flows, maybe it is better to move it to an array of objects.
There's a way you can add features little by little and get conditional, and a more flexible prompt flow, way better than sorted
It could look something like this (I'm sure you'll pick better names): variables:
- name: color
type: 'enum'
values: ['red', 'green']
default: 'red'
prompt: 'Favorite color?'
next:
# only one will execute
# but that can be decided by the tree visitor
# there's no need to pre-evaluate the flow
- case: 'red'
name: question_1
type: string
prompt: 'Name 3 red fruits'
next: # both will be executed
# no case here
- name: question_2
type: string
prompt: 'Another red question'
# neither here
- name: question_3
type: string
prompt: 'Another red question'
- case: 'green'
name: question_1
type: string
prompt: 'Name 3 mostly green country flags'
next:
- ...
I tried but it doesn't work. As they say, it is a |
Landed some of these in v1.23. |
Is your feature request related to a problem? Please describe.
Just some suggestions for the template creation DX
Describe the solution you'd like
I've come across a lot of things I'm wanted to do in the templates I'm writing, so I'm leaving the suggestions here. I'll try to keep them low-level and precise.
Some template questions have a logical order. Like asking if you want to generate A before asking for details for A generation.
This can be achieved by making
variables
an array or adding a separateprompts
array definitionSome prompts don't make sense depending on the answer to other prompts. Right now, the only way around this is
Allow template so specify variables cannot be changed from the CLI. This is useful for passing variables to the next templates in the chainto add
"only used if X == Y"
to the prompt textIt would be really nice to allow an extended template to only be executed under certain conditions.
Right now this can be achieved by defining a variable in the first one that gets propagate to the next one.
The next template then uses that variable to determine the value of
skip
, but that's a highly tight coupling.This could be implemented by allowing
extends
to accept an object withskip
(orcondition
) condition that works like the one in template files frontmatterThis can be as simple as listing the template variables or showing the entire yaml on
moon generate TEMPLATE --help
It would be nice to a
decription
ordocs
property to variablesSome kind of shared in-memory object would help a lot. We don't need to make the entire context mutable, a
cache
key-value map in the Tera context that can be modified by any template would be enoughI'm currently using extends to make a value available to all template files without copying and pasting code (imports do not work, but I think that is a Tera bug)
variables
This would allow base templates to pattern match the variables which may be very handy (think
babel-plugin-*
)Minor things
skip
vscondition
I find it odd to set when a file should be skipped instead of when it should run. To me,
condition: {{ debug }}
is more straightforward thanskip: {{ not debug }}
and I think it gets worse for more complex rules. Maybe it's just me, but I think there's a double negation hidden in there that always makes me write conditions wrong at the first time.Idk, it seems to me that there are less checking to be done when I can say "do this if X" then "skip if X" because (in my mind) that unfolds to "do not generate if X" and then X becomes more complicated because if it is
true
I need to returnfalse
because I'm deciding if I should not do the thing... Idk, maybe I'm crazy lolThe text was updated successfully, but these errors were encountered: