Replies: 4 comments 4 replies
-
Hi, we would love this! Could you send a PR with proposal? |
Beta Was this translation helpful? Give feedback.
-
The That may not be able to read "root" installed composer packages? |
Beta Was this translation helpful? Give feedback.
-
@TomasVotruba I'd definitely like to have a go at it, but I can't promise anything. Time-wise, I'm quite slammed. I have a rough idea for how it could work at least. |
Beta Was this translation helpful? Give feedback.
-
I've looked at this more recently. I can make this work but I'd need to tie into some kind of event bus to swap the composer dependencies during the execution of the rule and then restore Rector's composer dependencies after the rule has executed. |
Beta Was this translation helpful? Give feedback.
-
Sometimes it would be better if rules could be aware of the composer.json or composer.lock file of a project it's being used on.
For example, when I created the assertStatusToAssertMethod rule for Laravel, the rule is now slightly problematic because the possible conversions that occur as specific to the version of the framework that is installed. In some instances, the rule will convert the code to use a method that isn't available.
While some of this could be configured via options to specify which methods are available, it seems better to just provide a mechanism for rules to know what versions of PHP or packages are installed within the project.
An example of what this should be like is the Composer Runtime utilities.
Beta Was this translation helpful? Give feedback.
All reactions