Disabling recipes should be considered once more

[Bananeweizen]

I know there have been multiple discussions and issues about disabling recipes. The arguments on why that feature doesn't exist are mainly:

• recipes need to be chained, and disabling one recipe might break other recipes
• instead of disabling recipes, users shall report bugs about broken recipes

However, that totally misses the scaling problems that I've encountered again and again now: When a composite recipe grows, then there comes a point for every user where it contains a nested recipe that just doesn't fit the own requirements, conditions and environment. Some simple examples:

• org.openrewrite.java.testing.junit5.JUnit4to5Migration adds maven-surefire and similar to every POM that doesn't have that dependency. I have an entirely different maven test runner (tycho-surefire) and I don't want additional maven-surefire dependencies
• org.openrewrite.staticanalysis.CodeCleanup is great. Except for the fact that its parenthesis removal is unwanted in my team, because we prefer readability (and humans sometimes need some redundancy, even though the compiler may not need it).

For me this often leads to a workflow of:

• add a composite recipe and run
• notice all the unwanted stuff from that run
• comment it out, and instead copy all the contained recipes into the rewrite.yaml
• repeat until no unwanted changes are triggered

That doesn't scale well:

• It's a lot of work to get rid of 1 out of many child recipes.
• All version changes of composite recipes need to be copied to my own configuration.
• I'm much more unhappy about unwanted changes appearing again and again (from unwanted enabled recipes) than I'm unhappy about missing some rewrite opportunities (from impossible chaining due to disabled recipes).

I'm not sure if others just don't OpenRewrite regularly (so they can ignore the unwanted changes easily when committing after a one-time run), or if most people just apply one recipe or one category of recipe. But I would expect to see more people with similar problems in the future, when adopting OpenRewrite more broadly.

[timtebeek]

hi @Bananeweizen ; appreciate you starting a broader discussion where it's less fleeting than in Slack. Similar feedback has been a big motivator for us to revise the recipe builder that we offer at https://app.moderne.io/builder. There folks can now much more easily see what makes up a composite recipe that we offer, and choose to exclude certain recipes from that composite. Then you can download the resulting recipe and share and version that in a company specific recipe jar. Here's a quick preview of what that looks like in practice. Notice how you can drill down and search on the right, then select and edit or even remove nodes from this interface.

We believe this new builder goes a long way towards creating recipes that fit just right for your organization & needs, and are curious to hear your thoughts. As always we remain open for further feedback!

[Bananeweizen]

Thanks @timtebeek, that looks like it might make the management of recipes more simple. I still have to do some more experimenting, as my current workflow is based on running rewrite:discover and then mangling that output into a custom list of enabled and disabled things.

You may want to consider some of these for further improvements:

• There is little traceability from the custom recipe to the original one (and traceability is quite important in some process heavy companies). You may want to add some more "metadata", e.g. in the description (like "copy of org.rewrite.foo, created 2024-05-24").
• Recording the changes done by the user of the builder UI in the same metadata/comments/description would be even more awesome. That might even allow "automatically refreshing" the custom recipe after the original recipe has changed.

[timtebeek]

Good suggestions, thanks! I'll be sure to pass them on to the team. Note that you can also work on multiple recipes in parallel already in the builder, and we have plans to allow you to sync those recipes to a recipe git repository to make things even more convenient. That might then also take care of some of your concerns regarding traceability.

[gjoseph]

In some ways, what @Bananeweizen suggests kinda sounds (to me) like a (potential) recipe one could apply on another recipe (rather than on their project's code).

For my current simplistic case, I wanted to disable https://app.moderne.io/recipes/org.openrewrite.java.migrate.javax.AddCommonAnnotationsDependencies from org.openrewrite.java.migrate.UpgradeToJava21. What I'm ending up doing is adding custom recipe that does the inverse of the one I wanted to disable: it removes the dependency. That way, I'm always running the latest UpgradeToJava21 without having to maintain my own copy of it. Bit clunky, but, for now it works.

[okundzich]

I'm not sure how useful such diffing would be as recipes can also change, but the names remain the same. OSS recipes are community best effort with consumers usually curating their own. Storing recipes in github and versioning them there would also help.