Configuration option to set relative paths in include_paths to be relative to phpcs.xml file.

[cdayjr]

I'm currently having with the installed_paths being relative to the PHP_CodeSniffer install in that if I have rulesets installed in a specific project I can't use them without also installing them globally on my system. I'd prefer to keep the rulesets self contained to what they apply to.

I think having an option to make that path relative to the XML file would solve the issue completely, as one can easily deal with the directory structure in a project. As an option, if it keeps the default behavior as-is, we wouldn't have to worry about any breakage for anyone's current workflow.

[jrfnl]

@cdayjr You can set the installed_paths from within a custom project ruleset phpcs.xml.dist file like so:

<config name="installed_paths" value="vendor/phpcompatibility/php-compatibility"/>

That way they are only set for that particular project.

Or install both the external rulesets + PHPCS via Composer and use the DealerDirect Composer PHPCS plugin to set the installed_paths. That way the paths will only be set for the project local install of PHPCS, not for your global install.

[cdayjr]

If I use a relative path that doesn't start with ., that seems like it's relative to wherever the command is ran, not relative to where the xml file is. This is OK if I plan on always running the command from the root of the project, but my vim syntastic setup does not work that way and I'm sure other editor integrations do not.

Installing the dealerdirect composer plugin may solve this but I'd rather be explicit about what's installed in the xml file.

[c33s]

kind of similar problem #2776

[ktomk]

@cdayjr You can set the installed_paths from within a custom project ruleset phpcs.xml.dist file like so:

<config name="installed_paths" value="vendor/phpcompatibility/php-compatibility"/>

Another alternative is to announce the path as relative (to the PHP_CodeSniffer installation path inside the vendor directory):

  <config name="installed_paths" value="../../phpcompatibility/php-compatibility"/>

I found it more stable regardless where the vendor folder is, e.g. not explicitly in ./vendor. @jrfnl

If I use a relative path that doesn't start with ., that seems like it's relative to wherever the command is ran, not relative to where the xml file is. This is OK if I plan on always running the command from the root of the project, but my vim syntastic setup does not work that way and I'm sure other editor integrations do not.

For name="installed_paths" I found it relative to PHP_CodeSniffer installed path, which is not relative to working directory the command is run in nor relative to the XML file. @cdayjr

I have to admit, much more straight forward for paths relative to the XML file I found the <rule> element which supports XML relative paths. It fatal'ed in auto-loading then, fix suggestion in #3369.

(comments against PHP_CodeSniffer 3.6.0)

[internalsystemerror]

@ktomk Thankyou! I've been struggling to figure out why installed_paths wasn't being used in the phpcs.xml when as far as I could tell from these issues, it should be! Using the path relative to the PHP_CodeSniffer installation allows it run as expected.

[ktomk]

@cdayjr Could they please elaborate on the "not planned" close reason?/message? Others are fine that this is closed, at least for now, but we are nevertheless eager to learn more about theirs rationale of the action to close the issue which has been added the Core Component: Config & Ruleset & CLI options label on Jul 31, 2023 by jrfnl Juliette and Type: enhancement label on Dec 15, 2019 by gsherwood Greg Sherwood.

Theirs most recently have left a couple of descriptions via that not planned label (Won't fix, can't repro, duplicate, stale), so which one of those in specific and/or any references are much appreciated next to the action itself — for a better understanding.

Is this solved in (now upstream) PHPCSStandards/PHP_CodeSniffer (See issue #3932 for more information.) from theirs perspective?

Thanks for their reading and sharing any theirs considerations @cdayjr .