On 08.09.2016 at 12:35, Lester Caine wrote: > On 08/09/16 09:24, Daniel Morris wrote: >> On Thu, 8 Sep 2016, at 09:07 AM, Lester Caine wrote: >>> I've just been through an exercise to give PHP_CodeSniffer a go on my >>> code base. I've not worried too much about that in the past since >>> Eclipse in general flags style problems as well as simple errors. This >>> is a package that SUSE does not support, so the current install path is >>> just PEAR. I don't see packages like this as a library that my sites >>> use. It is a stand alone tool ( and a command line one at that :) ) so >>> how would loading that be managed if PEAR is not available? >> >> PHP_CodeSniffer is already compatible with Composer, and Composer has >> the ability to specify dependencies, and dependencies intended for >> development. After running composer install you can execute >> `vendor/bin/phpcs`, and if you were working collaboratively, >> collaborators would all have the same toolset that you have. > > I know this is a problem for PHP_CodeSniffer to rework it's > documentation,
The docs seem to be fine: <https://github.com/squizlabs/PHP_CodeSniffer#installation>. > but it is a chicken and egg. PEAR provides a framework to > store things like PHP_CodeSniffer in the common area away from our web > folders. A similar set of guidelines to install via composer are needed > as an alternative and those are not currently in place? The `global` command appears to solve that: <https://getcomposer.org/doc/03-cli.md#global>. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
