Best practices on handling large numbers of recipes?

[ericrrichards]

I'm building an OrchardCore-based application, and we have a large number of content items that we want to lay down when we install a new instance or tenant of the application. For instance, we have a reporting engine, and we use Orchard ContentItem documents to hold the parameters of each report. When we install, we want to give the customer the fifteen or twenty standard report definitions out of the box.

I have a setup recipe that I created to apply the necessary features, apply themes, set default settings, and add this content.

/Recipes    
    setup.recipe.json

The content items got rather large, and so I split that out into another recipe, and called it from the first recipe with a recipes step

/Recipes
    setup.recipe.json
    content.recipe.json

Now we've updated one of these report definitions on our reference instance, exported it, and want to update the content that is setup on new tenants. Diffing the content.recipe.json gets very painful, so I've split things out again, to make each content item an individual recipe, and the old content.recipe.json recipe has replaced its Content steps with Recipe steps
Now I have a structure like this:

/Recipes
    setup.recipe.json
    content.recipe.json
    report.A.recipe.json
    report.B.recipe.json
    ....
    report.Z.recipe.json

Out-of-the-box, I don't think I can put these child recipes in folders to clean things up and stay organized, because the stock IRecipeHarvester only looks in the /Recipes directory, not in any subdirectories. Or if I can, I didn't do it right when I tried to do it...

I think this leaves me with two options:

• Live with the current flat structure
• Write a new implementation of the IRecipeHarvester that enumerates subdirectories

[hishamco]

I don't think there's an issue if you split your large recipe into mutiple recipes