codacy / codacy-codesniffer Goto Github PK

Some plugins in PHP Code sniffer have its documentation as comments in the code.
Acceptance criteria:

• We have documentation for every pattern
• Documentation update is automated for every pattern

There is variation in the Php_CodeSniffer 3.6.2 plugin that we use it for lint in our IDE and this plugin used by Codacy.
As after being identifying and fixing all the issues, we still get a bunch of issues showing up in the Codacy.
P.S. : We are using the default version of Codacy Plugin

Each Codesniffer plugin has a docs parser that needs to be implemented.
It would be nice to make it more generic by generating through PHPDoc so that we have the same behaviour for every plugin.

Now that my custom phpcs.xml is working and phpcs isn't complaining about unable to find sniffs (thanks for the phpcs/slevomat update). I'm seeing an issue with one of the included sniffs

    <rule ref="SlevomatCodingStandard.Files.TypeNameMatchesFileName">
        <properties>
            <property name="rootNamespaces" type="array">
                <element key="src" value="RootNamespace"/>
            </property>
        </properties>
        <exclude-patter>src/namespace/Classname.php</exclude-pattern>
    </rule>

I'm getting this issue

Class name RootNamespace\namespace\Classname does not match filepath /src/src/RootNamespace/namespace/Classname.php

it should be trying to match /src/namespace/Classname.php.
It's as if the properties I've defined in phpcs.xml are being overwritten?

or (more likely) : as if my project is extracted to a /src directory on the phpcs virtual-machine and the rootNamespaces property I've defined is just being ignored (vs overwritten)

The file specified by exclude-pattern is not throwing an error. so <exclude-pattern> is working

Could it be possible to add the Slevomat Coding Standard's rules to the available ruleset of PHP codesniffer ?
From the tool pattern list as well as from the configuration file.

I am currently using this standard trough a composer installation but this is of course not working in Codacy as it doesn't install the dependencies.

I thought that including it by default would be a good idea as it is a quite used standard and as this is what you did with angular plugin and eslint.

I am wondering how it is possible to add more sniffer like:

• https://github.com/WordPress/WordPress-Coding-Standards
• https://github.com/PHPCompatibility/PHPCompatibility

Right now locally is enough to install it with composer but on the codacy wiki there is no explanation how to use them.

When running the tool on version 1.8.3, it is failing with the following error:

Error executing the tool
java.lang.Exception: 
CodeSniffer exited with code 255
stdout: 
stderr: PHP Fatal error:  Uncaught Error: Class 'XMLReader' not found in /opt/docker/app/.composer/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/I18nSniff.php:646

We are currently in the process of migrating our static analysis away from GitHub Actions and over to Codacy but have noticed that the magento/magento-coding-standard package is still sitting at Version 6. This version was released over 3 years ago and does not cover the current versions of Magento. There is a pending PR that has been open since February of this year (#256) which addresses this.

Is there any ETA on when this will be merged?

When running the tool with slevomat-cs, it is giving this error:

Error executing the tool
java.lang.Exception: 
CodeSniffer exited with code 255
stdout: 
stderr: PHP Fatal error:  Uncaught Error: Class 'PHPStan\PhpDocParser\Parser\TokenIterator' not found in /opt/docker/slevomat-cs/SlevomatCodingStandard/Helpers/AnnotationHelper.php:249
Stack trace:
#0 /opt/docker/slevomat-cs/SlevomatCodingStandard/Helpers/AnnotationHelper.php(228): SlevomatCodingStandard\Helpers\AnnotationHelper::parseAnnotationContent('@return', 'void')
#1 /opt/docker/slevomat-cs/SlevomatCodingStandard/Helpers/AnnotationHelper.php(129): SlevomatCodingStandard\Helpers\AnnotationHelper::getAnnotations(Object(PHP_CodeSniffer\Files\LocalFile), 48)
#2 /opt/docker/slevomat-cs/SlevomatCodingStandard/Helpers/SuppressHelper.php(18): SlevomatCodingStandard\Helpers\AnnotationHelper::getAnnotationsByName(Object(PHP_CodeSniffer\Files\LocalFile), 48, '@phpcsSuppress')
#3 /opt/docker/slevomat-cs/SlevomatCodingStandard/Sniffs/Functions/UnusedParameterSniff.php(45): SlevomatCodingStandard\Helpers\SuppressHelper::isSniffSuppressed(Object(PHP_CodeSniffer\Files\LocalFile), 48, 'SlevomatCodingS...')
#4 /opt/docker/composer/vendor/squizla in /opt/docker/slevomat-cs/SlevomatCodingStandard/Helpers/AnnotationHelper.php on line 249
                
    at codacy.codesniffer.CodeSniffer$.$anonfun$apply$1(CodeSniffer.scala:51)
    at scala.util.Try$.apply(Try.scala:210)
    at codacy.codesniffer.CodeSniffer$.apply(CodeSniffer.scala:25)
    at com.codacy.tools.scala.seed.DockerEngine.executeTool(DockerEngine.scala:53)
    at com.codacy.tools.scala.seed.DockerEngine.$anonfun$main$2(DockerEngine.scala:35)
    at scala.util.Success.map(Try.scala:262)
    at com.codacy.tools.scala.seed.DockerEngine.$anonfun$main$1(DockerEngine.scala:27)
    at scala.util.Success.flatMap(Try.scala:258)
    at com.codacy.tools.scala.seed.DockerEngine.main(DockerEngine.scala:26)
    at codacy.Engine.main(Engine.scala)

Parameters are defined in the patterns.json, but not in the description.json file.
This makes the UI skip them.

codacy-plugins-test json tests are skipped in CI:

Acceptance criteria

No parameters are deleted and codacy-plugins-test json test is enabled and green in CI

Fixes #27

The current build pulls in "squizlabs/php_codesniffer=2.9.1" which was released on May 21, 2017
Ideally we should be able to use the ^3.0 version (that will pull in the latest 3.x which as of right now is 3.3.1). The downside is if someone hasn't updated their sniffs to be up to date with the latest CodeSniffer package they will no longer work. However it has been over a year and they provide a guide to upgrade

It does look like the standards which you pull in as defaults all support php codesniffer 3.0+ though you would probably have to update to a later branch/tag on most of them.
The only one I see with a potential issue is Magento though you can pull master down and it supports version 3+.