Better documentation for installing custom standards
I just wasted quite a bit of time trying to figure out how to get phpcs to recognize a new custom standard. There is a lot of information/documentation so I apologize if I missed it. However, if it's there, it seems very easy to miss. This should be front and center, easy to find, so we can create easy rules (that can expand on already existing ones) to load in our editors like VSCode.
Desired Use Case: To create my own "MyCustomStandard" which expands on (or limits/modifies) PSR12 that I can reference just as MyCustomStandard. Just like you can with PEAR or Squiz or any of the others. Maybe I just want 8 spaces instead of 4 lol 🤷♂️
I created my own directory to house the standards so I don't risk them being lost in the future at: /Users/[username]/.phpcs/standards
Then, after various searches, I figured out how to add the directory via: phpcs --config-set installed_paths /Users/[username]/.phpcs/standards
With my own directory inside the standards directory for my custom standard, named MyCustomStandard.
From various searches and everything, I was trying to use the file name phpcs.xml. PHPCS would not find my new custom standard. Finally, after skimming over the source code, I decided to try ruleset.xml. Bingo, it now finds it!
There is a lot of documentation about CLI usage.. but this most basic usage seems to either be overlooked or buried in information overload.
Well, a lot of what you are describing here is explained in https://github.com/squizlabs/PHP_CodeSniffer/wiki/Coding-Standard-Tutorial
Once you have created your external standard, you will also need to register it with PHPCS using https://github.com/squizlabs/PHP_CodeSniffer/wiki/Configuration-Options#setting-the-installed-standard-paths - or if you will install the standard with Composer, you can use the PHPCS Composer plugin to automatically register the standard with PHPCS.
Generally speaking this is an advanced usecase though, which is why the information is not with the "basic usage" information, but in the advanced usage/sniff developer sections.
Hope that helps (a little?).
I disagree that that is 'advanced usage'.....It's the exact same thing as people do with an eslintrc file in node projects, which is completely standard practice for any significant project. Customizing php linting rulesets should be a standard process for php projects. If it is not standard, it is probably because php developers don't do linting (which in my experience is unfortunately true, and a huge problem) or because it's rather non-straightforward to figure out, as @WadeShuler is pointing out.