Proper way to modify getRecipeList based on examining the entire project

[crankydillo]

Currently, I have a set of recipes that simply return a recipe list. However, I need to create a noop situation based on looking at the entire project I'm rewriting. I assume I need to do this with a Scanning recipe. I know there's some issues about using a scanning recipe as a precondition in a declarative recipe, but mine is imperative. The only programmatic way I'm seeing is through something like doAfterVisitor with visitors from the recipe list done within ScanningRecipe::getVisitor(T acc). The doc still talks about Recipe::doAfterVisit (ex), but I think that might be outdated.

Is there an idiomatic way to do this? Some preliminary attempts with doAfterVisitor aren't working quite as I expect. Even if they do, I wonder if I'm going to lose the nice reporting stuff you get at the end wrt which recipes did modifications.

Thanks!

[crankydillo]

doAfterVisitor can't be the sole answer. It skips a lot of stuff, specifically in scanning recipes that come in the recipe list.

[shanman190]

So I would avoid getRecipeList unless you're always wanting that set of recipes to run. Even in which case, if you're trying to do parameters it can sometimes behave weirdly.

For optional execution, I'd probably use a scanning recipe, then in the edit phase use various attributes in the accumulator object to decide which recipe's visitors should be used. I'd just use the visitors directly rather than doAfterVisit as well.

Ie.

new MyRecipe(..).getVisitor().visitNonNull(tree, ctx)

[crankydillo]

Understandable, but unfortunate if true. Conditionally adding recipes sure seems like it would be a normal-ish use-case (as mentioned docs still refer to that concept:). Our use-case is internal spring-boot-like updates. We're doing it like rewrite-spring and rewrite-migrate-java, where the start of the recipe list begins with an upgrade to the prior version. However, we were hoping to 'short-circuit' once we reached a version that wasn't applicable to the project being updated. In other words, don't run v1->v2 upgrade recipe, which just provides a recipe list, if project is already on v2.

[shanman190]

Preconditions in the visitors or declarative recipes can be one way to deal with this.

The reason that OpenRewrite proper chooses not to do the same is because 1) sometimes things were missed in previous manual migrations and 2) sometimes new recipes are added to old versions. Each individual modification recipe of the larger Spring Boot migration recipe being designed to back off as soon as it knows that it has no work to do means that these backtracked feature adds can work still, but consumed wall clock time on an individual recipe basis is minimized.

You can achieve what you're wanting by writing a precondition recipe which could use DependencyInsight as part of its scan phase. Within the edit phase of this recipe, it would then mark with a search marker all source files as long as you found the old dependency version. It's not a very complicated recipe to write. I'd then use this on the declarative YAML recipes with a static recipe list to just make things simpler to maintain overall.

[crankydillo]

Ok @shanman190 . We'll proceed with these answers for now:)