Originally, the PHP 5.3 was removed, because Travis misconfiguration (32855d5beed16d6b68faea9bb0818c34bf7da9fc). However, seems most PHP 5.3 code is still there. This will attempt to restore such compatibility.

The --json support is not added, see notes below.

This is needed for projects that support old versions, example:

• https://github.com/zf1s/zf1

As the version still won't be tested in CI, such use will be at their own risk, as this project doesn't CI test those versions.

PS: once this project CI is migrated to GitHub actions and setup-php, then PHP 5.3 support can be enabled in Ci. Also, php 5.3 can be enabled in Travis, likely the original commit author did not know-how.

PS2: This can be seen in action here: https://github.com/zf1s/zf1/pull/66

There were many classes combined into single files, which isn't recommended and makes maintaining hard.

For example; Did you know that \JakubOnderka\PhpParallelLint\ArrayIterator was actually located in src/Settings.php. Not where you'd expect it to be.

This PR moves all these classes to their own files, and configures Composer to use a PSR-4 autoloader instead of a classmap.

Closes #25 Closes #26

I am not sure exactly what the problem is, but parallel-lint exits with "Error in skip-linting.php process" on php 8, you can check the full output at https://travis-ci.org/github/Seldaek/monolog/jobs/689943262#L395

While I'm glad this was forked into an org, so that if the current maintainers don't want to do it anymore, they can easily add more (vs just being in a users namespace) maintainers etc.

It does seem like the current maintainers aren't that actually that active (which is certainly understandable given COVID-19), but it's slightly concerning when they've only recently taken over the project.

To that extent, can we get more people involved to help this? Numerous people are still waiting on various cleanup from the forking and renaming, to deal with the deprecated/abandoned warnings when running composer.

Originally filed at https://github.com/php-parallel-lint/PHP-Console-Highlighter/issues/9 but I'm not sure why I put it in there

Depends on #45, test results are available at roelofr:#1, which merge into that master branch.

I'm still seeing errors on this branch, very wierd ones at that:

Fatal error: Interface 'JsonSerializable' not found in /home/runner/work/php-parallel-lint/php-parallel-lint/src/Error.php on line 4

I don't know why, but the Json class seems unavailable, although the json extension is enabled.

On PHP 8.0 I even saw Fatal error: Uncaught Error: Call to undefined function token_get_all(), which is a built-in and should always work.

Some wierd stuff going on here... :thinking:

Will close #44.

Hello

I'm trying to build the .phar file version and I'm thus following the guide as described in your README.md file (https://github.com/php-parallel-lint/PHP-Parallel-Lint#create-phar-package)

• git clone https://github.com/php-parallel-lint/PHP-Parallel-Lin
• composer update
• Download of box is OK
• Building the phar is KO with the following message :

php box.phar build
Building...

[RuntimeException]
failed to get contents of 'C:\temp\PHP-Parallel-Lint\parallel-lint.php'

build [-c|--configuration="..."]

• The box.json file mention parallel-lint.php for the main key while the file didn't have the .php extension. So, I edit the file and remove the .php extension. I've thus "main": "parallel-lint", in box.json
• I run php box.phar build once more and now building is correct.

But, now, running php parallel-lint.phar throw an error:

PHP Fatal error:  Cannot declare class ComposerAutoloaderInit8d3d5124130cbc6652f1aad8a66cf923, because the name is already in use in phar://C:/temp/PHP-Parallel-Lint/parallel-lint.phar/vendor/composer/autoload_real.php on line 5

Can you take a look please ?

Note: I've also tried https://github.com/box-project/box for creating the phar but here too, it doesn't work.

PHP Console Highlighter 1.0.0 has just been released.

This PR adds cross-version support for both PHP Console Highlighter < 1.0.0 and 1.0.0+ to PHP Parallel Lint, which allows people to update the Highlighter dependency to the latest version.

Includes changelog entry to allow this PR to still be included in the 1.3.2 release.

Ref: https://github.com/php-parallel-lint/PHP-Console-Highlighter/releases/tag/v1.0.0

Related to #44, follow-up PR to #46

Commit Details

GH Actions workflows: fix PHP set up step

To disable code coverage, the coverage key should be set to none. false is not a valid (or supported) value, so the behaviour may be unpredictable.

Ref: https://github.com/shivammathur/setup-php#disable-coverage

GH Actions: run the tests against all supported PHP versions

The original Travis script ran the following commands against all supported PHP versions, but didn't test the phar:

  - composer test
  - ./parallel-lint --exclude vendor --exclude tests/examples --no-colors .
  - ./parallel-lint --exclude vendor --exclude tests/examples .

The current test job only ran the unit tests against PHP 5.4. It did not run the integration test (running Parallel Lint against its own code) via a direct call to the script anymore at all. The integration test was basically now only being run for the phar and only in one flavour, though it did do that on all supported PHP versions.

This commit:

• Removes the job which only ran the unit tests against PHP 5.4.
• Adds the running of the above three commands (unit tests and two versions of integrations tests runs via a direct call to the script), to the job which also runs the integration tests via the phar file.
• Updates the command line parameters used for the phar run to be the same as those used for the direct script call integration tests.

GH Actions: actually get the tests running on all PHP versions

This fixes the problem originally identified by @roelofr with the Fatal error: Interface 'JsonSerializable' not found error.

The problem had nothing to do with the PHP setup, but everything with some inane setting of the Nette testing framework as can be seen in the transcript of older, failing trial runs done by @roelofr while setting up the GH Actions workflows:

Run composer test
> @php vendor/bin/tester -p php tests
 _____ ___  ___ _____ ___  ___
|_   _/ __)( __/_   _/ __)| _ )
  |_| \___ /___) |_| \___ |_|_\  v2.3.5

Note: No php.ini is used.

The key here is the Note: No php.ini is used..

As the system php.ini was not being used, no extensions were loaded, which was causing the errors.

This is a change which was introduced in Nette Tester 2.0.0. As of that version, you need to always tell the Nette testing framework explicitly which php.ini file to use, -C tells it to use the system-wide php.ini, with -c you can specify a path to a php.ini file and by default no php.ini is used. (honestly, why did anyone ever think making that the default was a good idea ?!!?)

As the tests will be running on different versions of the Nette Framework, Nette 1.x for PHP 5.4 and 5.5 and Nette 2.x for PHP 5.6+ and Nette 1.x, does not yet support the -C option and breaks when it is used, I've added a second test script to the composer.json file with the correct command line options to run Nette on PHP 5.4/5.5 and added conditions to the GH Actions workflow to use the correct script depending on the PHP/Nette test framework version being used.

Refs:

• https://tester.nette.org/en/running-tests#toc-c-path
• https://tester.nette.org/en/guide#toc-supported-php-versions
• https://github.com/nette/tester/releases/tag/v2.0.0

GH Actions: allow for manually triggering a workflow

Triggering a workflow for a branch manually is not supported by default in GH Actions, but has to be explicitly allowed.

This is useful if, for instance, an external action script or composer dependency has broken. Once a fix is available, failing builds for open PRs can be retriggered manually instead of having to be re-pushed to retrigger the workflow.

Ref: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

GH Actions: report CS violations in the PR

The cs2pr tool will allow to display the results from an action run in checkstyle format in-line in the PR code view, which should improve usability of the workflow results.

This implements this for the style check command.

Includes switching the PHP version to PHP 7.4, as PHP 8.0 is not fully supported yet in PHP_CodeSniffer (full support expected in PHPCS 3.6.0).

Ref: https://github.com/staabm/annotate-pull-request-from-checkstyle

~~GH Actions: report linting violations in the PR~~

~~The cs2pr tool will allow to display the results from an action run in checkstyle format in-line in the PR code view, which should improve usability of the workflow results.~~

~~This implements this for the results of running Parallel Lint over its own code.~~

~~This also implicitly acts as an integration test for the checkstyle output and the cs2pr integration.~~

~~Ref: https://github.com/staabm/annotate-pull-request-from-checkstyle~~

GH Actions: clean up

• Remove the now redundant Travis script.
• Remove the reference to the Travis script from .gitattributes and add the new .github folder.
• Update the "Build status" badge in the README to show the result of the GH Actions run instead of Travis.

Supersedes and closes #54

GH Actions: allow for testing on PHP 5.3 🆕

In anticipation of PR #51 being merged, I'm already adding an extra step to the test job.

PHP_CodeSniffer has a minimum PHP requirement of PHP 5.4, which would block the composer install on PHP 5.3.

By removing that dev dependency ahead of the composer install, the test workflow can also run on PHP 5.3.

GH Actions: fix phar creation 🆕

The phar file should only contain the files of PHP Parallel Lint and any non-dev requirements. It should not include the dev requirements of this package.

As things were, it did.

Fixed now, by doing the composer install with the --no-dev option, both for the Test workflow as well as for the Release workflow.

GH Actions: switch execution order of unit vs integration tests 🆕

... and add continue-on-error to the first of the integration tests.

If/when any of the tests fail, execution of the Test job will stop.

Now, if there is a parse error in the code of any of the Parallel Lint files, with the test execution order as it was, that means the job would already fail on the running of the unit tests and stop there.

However to identify the parse error, the integration tests are more useful, so with that in mind, those will now be run first.

Secondly, if there is a parse error, the first integration test would fail and the second (with colours) would never get executed, while especially in the case of a parse error in the Parallel Lint code itself, it is useful to see the output of both these integration tests.

So, with that in mind, I've set the first of the two to continue-on-error. As the second integration test would fail anyway, this will never negatively impact the workflow success/failure marking in the end, while it does allow us to see the output of both integration test steps.

PHP 8.1: silence the deprecation notice about jsonSerialize() return type

As of PHP 8.1, PHP adds return type declarations to the PHP native functions.

For the JsonSerializable::jsonSerialize() interface method, the new signature is:

function jsonSerialize(): mixed {}

As this libary still supports PHP 5.3, it is not possible to add this return type as:

1. Return types weren't available until PHP 7.0 and
2. the mixed return type only became available in PHP 8.0.

For libraries supporting PHP 7.0+, it would have been possible to fix this by adding an array return type (higher specificity).

For libraries still supporting PHP < 7.0, there are two choices:

1. Either decouple from the JsonSerialize interface.
2. Or use a PHP 8.1 attribute to silence the deprecation notice.

As prior to PHP 8.0, attributes are ignored as if they were comments, it is safe to add the attribute to the library and IMO, this is prefered over decoupling the classes from the JsonSerializable interface.

To prevent PHPCS tripping up over "something" existing between the function docblock and the declaration, PHPCS 3.6.0 should be used, which is the first PHPCS version with full PHP 8.0 syntax support in the sniffs (albeit that there are still some small things to fix up in PHPCS).

Refs:

• https://wiki.php.net/rfc/internal_method_return_types
• https://github.com/php/php-src/pull/7051

PHP 8.1: silence the deprecation notice about RecursiveFilterIterator method return types

As of PHP 8.1, PHP adds return type declarations to the PHP native functions.

For the RecursiveFilterIterator, the relevant method signatures are:

• accept(): bool
• hasChildren(): bool
• getChildren(): ?RecursiveFilterIterator

As this libary still supports PHP 5.3, it is not possible to add this return type as:

1. Return types weren't available until PHP 7.0 and
2. the mixed return type only became available in PHP 8.0.

For libraries still supporting PHP < 7.0, there are two choices:

1. Either decouple from the interface.
2. Or use a PHP 8.1 attribute to silence the deprecation notice.

As prior to PHP 8.0, attributes are ignored as if they were comments, it is safe to add the attribute to the library and IMO, this is prefered over decoupling the classes from the interface.

To prevent PHPCS tripping up over "something" existing between the function docblock and the declaration, PHPCS 3.6.0 should be used, which is the first PHPCS version with full PHP 8.0 syntax support in the sniffs (albeit that there are still some small things to fix up in PHPCS).

Refs:

• https://wiki.php.net/rfc/internal_method_return_types

Thank you for keeping this tool alive, it is amazing! But I would like to propose a custom error hook or some callback which I can use to modify error before proceeding. This is the reason

Laravel & Blade

Laravel FW uses Blade as a template, which is then compiled into PHP files. So I'm running this code

php artisan view:cache # Compile all Blade templates
./vendor/bin/parallel-lint ./storage/framework/views

But if there is an error in Blade template, it shows error like this: Parse error: ./storage/framework/views/b89d10e4ca8386fb9f234e0b5a62798e71014114.php:66 Which says nothing, because it points into already compiled. However, there is a way how to map this error back into the original Blade file.

So if there would be some possible callbacks, I would use it to modify error back to the original file and line.

Is there a way how to make this possible? It would maybe require some config file instead of CLI arguments only. If you don't want to require any other package for config parsing (like Yaml etc), maybe just include PHP file with an array.

Includes:

• Renaming the files to reflect the name of the class therein and to use the php instead of phpt file extension.
• Updating the autoload-dev directive in the composer.json file.
• Updating the exclusions in the PHPCS config.

Note: using PSR-4 compliant *Test,php filenames will (temporarily) silently break the running of the tests for PHP 5.3-5.5 as Nette Tester 1.x can't find the tests anymore. We can ignore this for now as this will be fixed in one of the next PRs where the tests will switch over to the PHPUnit testing framework.

To allow to integrate it with CI directly, without installing it as dependency similar to this: https://github.com/overtrue/phplint#docker-cli

so we can use it this way

          - step:
              image: overtrue/phplint:8.1
              name: PHP Linting parallel
              script:
                - /root/.composer/vendor/bin/phplint ./

Disclaimer: I've not looked how the --show-deprecated option works internally, and maybe the idea below is not achievable at all.

While using the --show-deprecated option with PHP 8.1 against some large codebase, I was surprised that only a few cases were detected, when that version comes to lots of classes now requiring correct return type-hinting.

So, for example, this file / class:

<?php

class my_ite implements Iterator {
    public function current() {
        return 1;
    }
    public function key() {
        return 1;
    }
    public function next() {
        // do something.
    }
    public function rewind() {
        // do something.
    }
    public function valid() {
        return true;
    }
}

Does, in fact, miss a lot of return types (or #[ReturnTypeWillChange] attributes). See https://3v4l.org/bPN2V

But, parallel-lint does not detect them at all:

$ vendor/bin/parallel-lint --show-deprecated test.php 
PHP 8.1.9 | 10 parallel jobs
.                                                            1/1 (100 %)


Checked 1 files in 0.5 seconds
No syntax error found

(note, neither php -l test.php does)

So, I was guessing if, maybe, when the file (class) being linted does not have unknown dependencies (errors)... it would be possible to, effectively, try to run the file and get all those deprecation messages that aren't shown normally.

Again, surely this is a non-sense and crazy idea, I just discovered that my hypothetical (only, I was happy) 12 deprecation cases detected by --show-deprecated... they are going to be, in reality, some good hundred, heh.

Still I'm not sure to understand why some are detected (for example php_user_filter::filter($in, $out, &$consumed, bool $closing): int was perfectly detected and others (like Iterator::valid() : bool) aren't, unless you effectively "run" the file.

And that's the story and the (crazy) idea, thanks for the tool, it's really useful!

Ciao :-)

Currently, I do not see an option to log progress to a text file e.g. log which files have been processed.

My scenario ...

I am executing via PHAR 1.3.2 on the current folder:
C:/xampp/php/php C:\scms\parallel-lint.phar --exclude .git .

This particular local repository it is hanging for some unknown reason. This is the output ...

Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(
PHP 7.4.29 | 10 parallel jobs
............................................................   60/1169 (5 %)
............................................................  120/1169 (10 %)
............................................................  180/1169 (15 %)
............................................................  240/1169 (20 %)
............................................................  300/1169 (25 %)
............................................................  360/1169 (30 %)
............................................................  420/1169 (35 %)
.................................X..X.......................  480/1169 (41 %)
............................................................  540/1169 (46 %)
............................................................  600/1169 (51 %)
............................................................  660/1169 (56 %)
............................................................  720/1169 (61 %)
............................................................  780/1169 (66 %)
............................................................  840/1169 (71 %)
............................................................  900/1169 (76 %)
............................................................  960/1169 (82 %)
............................................................ 1020/1169 (87 %)
............................................................ 1080/1169 (92 %)
............................................................ 1140/1169 (97 %)
..........................^C

The ^C is me hitting the Ctrl+C after I've waited minutes.

When I exclude the "application" folder within the repository, it completes ...

C:/xampp/php/php C:\scms\parallel-lint.phar --exclude application --exclude .git .
Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(
PHP 7.4.29 | 10 parallel jobs
............................................................  60/179 (33 %)
............................................................ 120/179 (67 %)
...........................................................  179/179 (100 %)

Checked 179 files in 1.6 seconds
No syntax error found

Since the tool is multi-threaded, I assume that all but one thread completes all the other files in the repository except a single file (within the "application" folder) which a single thread stalls on. From the numbers above it will be extremely time consuming to attempt to isolate a single file amongst 990 files (1169 - 179) within the application folder using multiple --exclude parameters.

By logging progress to a file per file processed, this will help isolate the offending file. Maybe logging when a file as starting processing too?

Currently when running the application, the first line of the console output looks like this:

PHP 8.1.2 | 10 parallel jobs

I'd like to suggest including the name and version of this application in this line, like so:

PHP-Parallel-Lint 1.3.1 | PHP 8.1.2 | 10 parallel jobs

Opinions ?

This would make it more straight-foward for repos to ensure that every contributor runs the linting command with the same CLI arguments and would allow them to document this via a committed file.