Add composer runnable scripts for PHPStan & PHP-CS #881
Conversation
|
Not sure I get the purpose of this PR, @Steveb-p could you elaborate on why we might need it? |
|
@makasim The name for package in composer.json should match the name used in packagist to allow proper forking / repository override. https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository Use case for this is using your owned version of a library instead of the main one available in packagist - which is helpful when applying some small, custom patches without intent of maintaining a separate package. I do realize that there should really be no case that whole |
|
tps://packagist.org/packages/enqueue/enqueue/stats is a valid package located here https://github.com/php-enqueue/enqueue-dev/tree/master/pkg/enqueue The enqueue-dev repo is not even registred on packagist. |
|
Then the PR can be discarded. I can push those scripts declared in composer as a separate PR if you like or drop them entirely - or rename this PR - though I believe they might become helpful for potential contributors - allowing new ones to easily call common tasks without knowing their exact configuration / reading them from travis configuration file. I can also add a note to contributing.md regarding their use. |
That would be great. I am fine with either way. |
Steveb-p
force-pushed
the
match-packagist-name
branch
from
13fe8ca to
bfa6450
Compare
|
@makasim I've changed this PR into a one that introduces composer scripts instead only. Figured it would be ok if above discussion is kept instead of creating new PR. |
Steveb-p
changed the title
Steveb-p
force-pushed
the
match-packagist-name
branch
from
bfa6450 to
2fe7b9f
Compare
This allows for forks in composer requiring whole package (enqueue) to
work properly.
Also add code style commands as composer scripts for ease of use.
This allows calling for example
composer run cs-fix some-file.php.