feat: add drupal to RectorConfigBuilder::withComposerBased#8041
Conversation
|
Seems straightforward enough. Merged into dev main for drupal-rector. |
|
Looks good, let's give this a go 👍 |
|
Clean Drupal 11.3 install with ddev. With some composer magic. And then a debug run :) That sounds pretty good. :) |
|
Very nice work! :) Time to try on real projects, if all rules are applied |
|
I'll try later on some of our client projects. |
|
It applies all gucci, tried a few project and got applied rectors. I cant really test all :P But the sets were selected correctly and rectors were applies from the set. I did notice a small oversight. Originally for normal projects we added: And this also makes sense when you use the composer based set. You do not need to support multiple Drupal versions there. This only really makes sense for Drupal modules (packages). This needs disabling, so this needs to be added to the |
|
I'll move to putting any comments in the issue in rector itself (rectorphp/rector#9778) |
What
Adds a
drupaltoggle towithComposerBased()and the matchingSetGroup::DRUPALconstant, so a DrupalSetProviderInterfacecan expose composer-triggered sets keyed ondrupal/core:This mirrors the existing ecosystem toggles (
twig,symfony,laravel, …) exactly — one extra parameter wired into the same$setMap, plus the group constant. The set provider itself lives in the externalpalantirnet/drupal-rectorpackage, same aslaravel's provider lives inrector-laravel.Why
Companion to palantirnet/drupal-rector#370, which ships
DrupalSetProviderexposing the per-minor Drupal deprecation/breaking configs asComposerTriggeredSets in thedrupalgroup. Those sets stay dormant until core exposes thedrupal:toggle to opt into the group — this PR is that toggle. And ofcourse the original rectorphp/rector#9778Verification
tests/Set/SetManager/SetManagerTest.phpgreen.withComposerBased(drupal: true)registers thedrupalset group.