Replace contributing Goal 2 with a helper script

[milesfrain]

https://github.com/JordanMartinez/purescript-cookbook/blob/master/CONTRIBUTING.md#goal-2-setup-a-new-recipes-boilerplate-by-copying-a-current-similar-one

Thinking something like:

scripts/NewRecipe.sh MyNewRecipe
scripts/NewRecipe.sh MyNewRecipe HelloHalogenHooks

The second recipe name is an optional and defaults to HelloLog if not set.

I was initially thinking of allowing flags, but I think it would be simpler to just inherit the configuration of the copied recipe.

---

Old flags idea:

Flags could be:

--web Runs in browser
--node Runs in node
--cli Runs in node, but skip CI test
(no flags) 

Should include checks for incompatible flags, such as --node and --cli together, or let --cli override --node.

[JordanMartinez]

I really like this idea. Duplicating HalogenHooks recipes and updating them to something else was tedious to do in #177.

I think for now it is enough to just copy an existing recipe, renaming references to the old recipe name to the new one, and leave it at that. No flags needed.

For example, if I want to create a CLI app, I could run make new <RecipeName> DiceCLI to generate a recipe using DiceCLI as a base.

[afcondon]

I also really like this idea, and it immediately makes me think that there would be some emergent value to maintaining the links - both backward and forward, as is done for Git forks and some other things. But i think that would require some work to generate and maintain unique IDs so maybe it's a non-starter. Maybe there's a simple way to do it that hasn't occurred to me, so that's why i'm mentioning it.

[milesfrain]

maintaining the links

Do you mean remembering which recipes the new recipes were copied from?

I see the value of remembering forks with GitHub, but I don't see how this improves the cookbook unless there's diffing / rebasing capabilities from the original recipe. For many recipes, I think the copy origin will be pretty arbitrary.

[afcondon]

yes, that's true - i was thinking of the people extending existing recipes rather than just sort of hollowing them out like a "HelloWorld" program. (I was also thinking of the http://bl.ocks.org stuff that is used in the D3JS world but maybe that's a counter-example in some ways)

[JordanMartinez]

I don't see the point either of recording what recipe was used as a base for a new recipe. What would you do in situations where no recipe was used as a base at all? Why would a reader care? The "create new recipe by duplicating an existing one" idea exists solely for reducing the overhead of creating all that boilerplate.

[and-pete]

I don't see the point either of recording what recipe was used as a base for a new recipe.

Vaguely related to the idea above, but I think not worth re-opening #138 (porting HalogenClassic examples to HalogenHooks) for..

Do you think it would be worth having a link in each of the new Hooks README files to the Classic equivalent in the purescript-halogen repo?

This might prevent contributors unfamiliar with the ecosystem opening recipes for things that already exist in the purescript-halogen/examples folder.

And the main cookbook README might also include a similar note as what is done for the React/Elm ports. "A HalogenHooks port of DriverWebSockets from purescript-halogen/examples" (with corresponding link).

[JordanMartinez]

We could do that, but part of me wonders whether the HalogenClassic examples should be ported here or not.