You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a ticket to keep track of the changes which PHPCSUtils will need to account for by the time PHPCS 4.0 comes out.
No urgency until there is sight of a release date.
As a principle, the code in PHPCSUtils should work with PHPCS 4.x. External standard shouldn't need to do anything special if they only want to support PHPCS 4.x
If external standards want to continue to support PHPCS 3.x as well a PHPCS34Utils standard should be added to provide the compatibility layer, where necessary.
To do:
Work-around/account for the removal of the PHCPS native T_ARRAY_HINT and T_RETURN_TYPE tokens. squizlabs/PHP_CodeSniffer@8cba000
Possible solution direction:
Add a PHPCS34Utils standard similar to the principle of PHPCS23Utils to create the BC layer.
Remove the tokens from the static arrays in PHPCSUtils\Tokens\Collections.
In a __construct() method for the PHPCS34Utils sniff, add them back to the static Collections arrays if PHPCS < 4.x is detected.
For all other places these are used (if any), wrap them within a defined() check.
Other possible solution direction:
Have a PHPCS34Utils standard without any sniffs, but just with an <autoload> directive.
In a phpcs34-autoload.php file add the tokens back if they don't exist yet, but make sure that the PHP_CodeSniffer\Util\Tokens file is loaded first to prevent "constant already defined" notices.
(IIRC PHPCS itself doesn't wrap PHPCS native tokens in a if (defined()).)
Verify that any JS/CSS specific code doesn't start throwing errors now the tokenizers have been removed.
PHPCSUtils does not purposefully support JS/CSS anyway, but the backcompat functions and sister-functions for those in PHPCSUtils may have inherited support based on the PHPCS 2.x/3.x implementation. squizlabs/PHP_CodeSniffer@ea52e7b
Other notes (no sight yet of what the impact will be, if any):
PHPCS 4.x will drop support for PHP 5.
PHPCS 4.x will drop support for installation via PEAR.
The text was updated successfully, but these errors were encountered:
This is just a ticket to keep track of the changes which PHPCSUtils will need to account for by the time PHPCS 4.0 comes out.
No urgency until there is sight of a release date.
As a principle, the code in PHPCSUtils should work with PHPCS 4.x. External standard shouldn't need to do anything special if they only want to support PHPCS 4.x
If external standards want to continue to support PHPCS 3.x as well a
PHPCS34Utils
standard should be added to provide the compatibility layer, where necessary.To do:
Work-around/account for the removal of the PHCPS native
T_ARRAY_HINT
andT_RETURN_TYPE
tokens. squizlabs/PHP_CodeSniffer@8cba000Possible solution direction:
PHPCS34Utils
standard similar to the principle ofPHPCS23Utils
to create the BC layer.PHPCSUtils\Tokens\Collections
.__construct()
method for thePHPCS34Utils
sniff, add them back to the staticCollections
arrays if PHPCS < 4.x is detected.defined()
check.Other possible solution direction:
<autoload>
directive.phpcs34-autoload.php
file add the tokens back if they don't exist yet, but make sure that thePHP_CodeSniffer\Util\Tokens
file is loaded first to prevent "constant already defined" notices.(IIRC PHPCS itself doesn't wrap PHPCS native tokens in a
if (defined())
.)Closure
use
tokens will be parenthesis owners in PHPCS 4.xsquizlabs/PHP_CodeSniffer@08824f3
This affects at least the following:
BCTokens::ParenthesisOpeners()
BCFile::getMethodParameters()
/FunctionDeclarations::getParameters()
methods.BCFile::isReference()
/Operators::isReference()
methods.UseStatements::getType()
Probably won't have any influence/impact on PHPCSUtils. Needs verification:
PHPCSUtils does not purposefully support JS/CSS anyway, but the backcompat functions and sister-functions for those in PHPCSUtils may have inherited support based on the PHPCS 2.x/3.x implementation.
squizlabs/PHP_CodeSniffer@ea52e7b
Other notes (no sight yet of what the impact will be, if any):
The text was updated successfully, but these errors were encountered: