Refactor recipes + add nextjs recipe #815
Conversation
| recipeOptions.push(await recipe.getOptions?.(baseOptions)); | ||
| } | ||
|
|
||
| await baseRecipe.apply(baseOptions); | ||
| for (let i = 0; i < recipes.length; i++) { | ||
| await recipes[i].apply(baseOptions, recipeOptions[i]); |
There was a problem hiding this comment.
What do you think about unwinding these changes and requiring that recipes are encapsulated again given that they can create their own prompts and can encode their own "skipping" logic in the function itself?
There was a problem hiding this comment.
That was the aim to keep the recipes encapsulated, but I did split the prompts part into a separate step of each recipe, as I think it's preferable to do all the prompts before we start actually copying any files. I don't mind if we drop the skipping bit, that was just so we didn't have to duplicate that logic for the prompts and apply step for every recipe, but I think it's fine either way.
There was a problem hiding this comment.
That was the aim to keep the recipes encapsulated, but I did split the prompts part into a separate step of each recipe, as I think it's preferable to do all the prompts before we start actually copying any files.
In general, I think I prefer the recipe to be completely opaque to the caller: pass the base options and let the recipe know how to do everything else. I'm not sure having the prompts happen upfront is objectively better: Imagine there was an issue in one recipe, but you answered the questions for all of the recipes. It seems just as valid to answer some questions then do the related work, answer more questions, do more work. The one possible advantage is being able to cancel before you do any changes, but I also see that as a possible disadvantage when trying to debug or troubleshoot an issue (e.g. you run through the changes until just before the issue and you can inspect the state of the filesystem or running recipe while the prompt is waiting for input).
It's also possible that there are prompts that are only relevant after some other side-effects have run, which is fine: even with the proposed changes you can continue to prompt the user, but then I think the whole case for hoisting the prompts up becomes weaker still.
To summarize, my case for keeping recipes fully opaque is:
- The mechanism for running the recipes is trivial (
for recipe of recipes { await recipe(opts); }) - Reading a recipe is a complete description of the runtime behavior (rather than having to know about what each method does)
- Failing faster might mean troubleshooting issues is easier/quicker as we add more recipes
- More flexible: prompts are not special—they're just side effects
scotttrinh
force-pushed
the
807-edgedb-create
branch
from
3aece6b to
371ee67
Compare
jaclarke
force-pushed
the
create-nextjs
branch
from
75b48da to
26ce167
Compare
No description provided.