#70 look for further vendor/autoload.php locations to support in-project-dev-dependency installations
#71
Conversation
…oject-dev-dependency installations
…`doctrine/coding-standard` v4
| /** @noinspection PhpIncludeInspection */ | ||
| require_once $autoload; | ||
|
|
||
| return; |
There was a problem hiding this comment.
There's an argument for not breaking when the first one is found, depending what use cases you want to support.
If I build a PHAR or do a composer global require, or any other method where the tool has its own deps locally then I need to include both the tool's autoloader and the project's autoloader
There was a problem hiding this comment.
Wait this might not apply in your case if you're not depending on project reps being loaded
There was a problem hiding this comment.
I need to include both the tool's autoloader and the project's autoloader
This can happen when using classes from this project directly, but not with the bin/roave-backward-compatibility-check.php, which is closed for customisation.
There was a problem hiding this comment.
Not sure what you mean...
I mean does this tool need to autoload target project's classes?
There was a problem hiding this comment.
No, it doesn't, but you can use classes from this tool in your own project
There was a problem hiding this comment.
OK then it's sufficient to find 'our' autoloader 👍
There was a problem hiding this comment.
Then 🚢
Lemme finish this 🍺 and I'll release
Closes #70
I was trying to find a way to test this via
.travis.yml, but the problem is that I'd need to add a composervcsrepository and then use aHEADreference with some ugly hacks that will break everything, so I'd probably skip that for now.@ciaranmcnulty can you please review this one? Use
?w=1:-)