Wildcards for recipe enablement #4451
Unanswered
Bananeweizen
asked this question in
Ideas
Replies: 1 comment
-
Hi @Bananeweizen ; To remain predictable I think it's best we only activate explicit recipes, not recipes matching a particular pattern. What I can offer is a quick look at how we generate our documentation, which might help you automate some of the work you're doing:
Your situation could be even simplier; the key is using |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I maintain a huge rewrite.yaml with the enabled styles and recipes (1700 lines). Every other week I run rewrite discover and sync the output with my yaml file via BeyondCompare, to have the latest recipes enabled. I'd really like to be able to use wildcards for the recipe selection to shrink the size and to reduce the rate of changes. E.g.
org.openrewrite.*assert.*
to get everything related to assertions,com.foo.rewrite.*
to get all recipes in my own extension library,com.picnic.*nullable.*
to get the nullable related recipes of the picnic contributors. Would also reduce the editing for renamed recipes and similar.I'm aware that this might enable and disable recipes after upgrades, but since I fully version all my dependencies, the effective recipe list is still fully reproducable via git history.
Anyone here with similar challenges and wishes? Or would you recommend implementing a simple Java based recipe that does the same via class graph scanning?
Beta Was this translation helpful? Give feedback.
All reactions