WPCS 2.0.0: Remove the PHPCSAliases file #1596
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After extensive testing based on issues which were previously reported, I've concluded that the `PHPCSAliases.php` file can now be safely removed.
Test setup I've used to confirm this:
* Clean Composer install of PHPCS + WPCS _without the `installed_paths` config directive being set.
```json
{
"require": {},
"require-dev": {
"squizlabs/php_codesniffer": "^3.3",
"wp-coding-standards/wpcs": "^1.1"
}
}
```
* Basic PHPCS ruleset:
```xml
<?xml version="1.0"?>
<ruleset name="AliasFileTest">
<file>.</file>
<exclude-pattern>vendor/*</exclude-pattern>
<arg value="p"/>
<config name="installed_paths" value="vendor/wp-coding-standards/wpcs"/>
<rule ref="WordPress"/>
</ruleset>
```
* A PHP test file which would generate issues.
Tests I've run:
* Running `vendor/bin/phpcs` on the above (which would be with WPCS 1.2.1) works fine.
* Changed the `config` directive value to point to my local WPCS dev install:
`<config name="installed_paths" value="I:/path/to/WordPress-Coding-Standards/WordPress-Coding-Standards"/>`
* Tested again against the `develop` branch, still was working fine.
* Now we get to the interesting part: changed to this branch and ran it again. Still working fine.
* Changed the `<rule ref..>` to `<rule ref="WordPress-Core"/>` and still working fine.
* Changed the `<rule ref..>` to `<rule ref="WordPress.Security"/>`, i.e. not a registered standard, but a subcategory and still working fine.
Based on all this, I'm concluding that the WPCS autoloader in the PHPCSAlias file is no longer needed and can now be safely removed.
Refs:
* 1087
* squizlabs/PHP_CodeSniffer 1591
GaryJones
approved these changes
Dec 24, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After extensive testing based on issues which were previously reported, I've concluded that the
PHPCSAliases.phpfile can now be safely removed.Test setup I've used to confirm this:
installed_pathsconfig directive being set.{ "require": {}, "require-dev": { "squizlabs/php_codesniffer": "^3.3", "wp-coding-standards/wpcs": "^1.1" } }Tests I've run:
vendor/bin/phpcson the above (which would be with WPCS 1.2.1) works fine.configdirective value to point to my local WPCS dev install:<config name="installed_paths" value="I:/path/to/WordPress-Coding-Standards/WordPress-Coding-Standards"/>developbranch, still was working fine.<rule ref..>to<rule ref="WordPress-Core"/>and still working fine.<rule ref..>to<rule ref="WordPress.Security"/>, i.e. not a registered standard, but a subcategory and still working fine.Based on all this, I'm concluding that the WPCS autoloader in the PHPCSAlias file is no longer needed and can now be safely removed.
Refs:
installed_pathsonly set via a custom ruleset squizlabs/PHP_CodeSniffer#1591This is the last PR in the series to drop PHPCS 2.x support and the work related to issue #1048 can now be considered finished.
Closes #1048