Php-cs-fixer: PHP 7.3 support

[mxr576]

Hi,

Do you have any estimation when the PHP 7.3 is going to be supported by the fixer? I am running tests with the nightly builds of PHP 7.3 and those are failing because this library can not be installed with that PHP version. This is not a huge problem, because those builds can fail but I would not spend time on creating a workaround for this if PHP 7.3 supports comes soon to the dev.

[SpacePossum]

Hi!

TBH I haven't seen anyone working on PHP7.3 compatibility here yet so I cannot give an estimate on it.
I haven't seen a RC for 7.3 on PHP.net either, not sure what the state is so any links would be welcome :)

[mxr576]

Let me rephrase my question :) Is there any specific reason why this library does not allow to be installed on PHP 7.3? I'd rather expect a condition like this in the composer.json:

"php": "^5.6 || ^7.0", or just "php": "^5.6",

[Slamdunk]

I would not spend time on creating a workaround for this

Composer provides --ignore-platform-reqs for this purpose: https://getcomposer.org/doc/03-cli.md#install

[mxr576]

Thanks, I'll try it out, but my previous question still stands I think.

[SpacePossum]

Is there any specific reason why this library does not allow to be installed on PHP 7.3?

Yes :) We always only put the PHP versions in composer we feel confident the tool runs fine on it _and_ does a good job reading and fixing the PHP code written for that PHP version. The last bit makes the tool a bit more special than the typical project.
It wouldn't be the first time we get a BC break on a PHP minor which forces us to make changes to the fixer before we can ship it out for that PHP version.
Since we haven't done any testing on PHP 7.3 we'll not state we support it by putting it in composer.

[keradus]

To fulfill @SpacePossum answer, keep in mind that PHP is not following semver strictly, and they dont have BC promise for syntax. For that, any change of syntax (that is possible on each minor, all 5.6,7.0, 7.1, 7.2 introduced new syntax) is bc breaker for us.

To fulfill @Slamdunk answer, then you would need to set up PHP_CS_FIXER_IGNORE_ENV env var to be able to run the tool. Be warned that if we don't claim we support given PHP, you may experience wrong changes done to the codebase or crash of the tool.

[GrahamCampbell]

PHP is not following semver strictly

PHP is not following it, fullstop...

[lsv]

@mxr576
If you are using travis, you can add nighlty to allow failures in matrix

matrix:
  fast_finish: true
  include:
    - php: 7.1
    - php: 7.2
    - php: nightly
  allow_failures:
    - php: nightly

This will fail the nightly, but will still give green

[keradus]

@lsv no clue how it would help @mxr576 , even when on nightly build, he still won't be able to use PHP CS Fixer under it, as PHP CS Fixer doesn't support 7.3.
(if you were suggesting to PHP CS Fixer to do it, we already have nightly build in travis, which doesn't mean we fully support 7.3 syntax)

[sebastianblum]

Hello,

As you can see https://travis-ci.org/FriendsOfPHP/PHP-CS-Fixer/jobs/324488663 php-cs-fixer will run with php nightly / 7.3 at the moment.

I would allow PHP 7.3 that php-cs-fixer can be integrated in other PHP libraries or bundles like https://travis-ci.org/liip/LiipImagineBundle/jobs/324222961

If we allow PHP 7.3 in composer.json, we can add a warning while running PHP-CS-FIXER that PHP 7.3 is not fully supported yet - like a deprecation warning for PHP 7.3 in the 2.9 branch.

What do you think about?

//cc @dbu

[SpacePossum]

As we cannot state we support PHP 7.3 we are not going to express it in composer.json.
If you want to run the tool on PHP 7.3 before support is added you would have to update your setup for it.
Adding a deprecation warning for something we are going to support in the future makes no sense to me TBH.

We have this discussion whenever a new version of PHP is released in some form, maybe it would be best to add our POV in the docs so we don't have to redo it.

[dbu]

question would be whether to trust PHP to keep BC between minor releases. thing is either they did not in the past, or their definition of BC is not suitable for PHP libraries... in LiipImagineBundle we use styleci anyways, so does not matter.

i guess the general answer for the doc should be to run the cs fixer only on one build, which can be the one on an older php version. (i guess not many people are developping for php 7.3 exclusively...)

[julienfalque]

The main problem is not that PHP might break backwards compatibility but that it might introduce new syntaxes. If the code of PHP CS Fixer is not able to handle a new syntax, it might have unexpected behavior (e.g. break your codebase), even if PHP CS Fixer's codebase itself is compatible with new PHP version.

That means we need to update PHP CS Fixer own codebase but also make sure that all fixers have test cases that cover newly introduced syntaxes. This is why we prefer not claiming we support new PHP versions of PHP until we are confident we do.

[mxr576]

I totally agree most of the comments above, especially with @julienfalque's last one. Therefore I'd suggest to remove limitation from the composer.json that prevents installation of this library on PHP 7.3 (and causes failed builds on PHP nightly) and rather prevent its execution of a currently not fully supported PHP version.
I think it would be also important to allow to change phpcsfixer's exit code on a non-supported PHP version by using an environment variable, because that could be leveraged (in Travis CI or other places) to keep the PHP nightly test builds passing of an another PHP library.

[sebastianblum]

I created an issue in the composer repo https://github.com/composer/composer/issues/6965
I agree that it makes no sense to allow PHP 7.3 in composer.json if php 7.3 is not supported in the php-cs-fixer.

Another solution is to create an pre release of version 2.10 or 3.0 for php 7.3 which is not running at the moment and only shows an warning. But it does not break the composer requirements.

[julienfalque]

That would still require to loose the PHP version constraint so you can install and run the tool. But it doesn't make sense to me: code is either compatible or not, and using PHP version constraint with Composer is the best way to state PHP compatibility.

Just like @Slamdunk said (https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3323#issuecomment-351690076), you can simply workaround this with Composer commands in your PHP 7.3 build:

$ composer install --ignore-platform-reqs

or

$ composer remove friendsofphp/php-cs-fixer

@dbu's suggestion is the best answer I think: your builds should only run PHP CS Fixer on the lowest PHP version you support anyway.

[GrahamCampbell]

I think the current situation in this repos composer.json is the best option tbh. I don't think it should change.

[dbu]

agree with graham, i think its only a documentation issue to say what julienfalque explained here. and suggest to composer require the fixer in just one matrix entry where the php version is a supported php version.

[julienfalque]

See #3697 for PHP 7.3 support progress.

[garak]

I think that this issue should be re-opened, now that PHP 7.3 is officially released.
I'm not speaking of supporting new features (like in #3697), but just to be able to install this library on PHP 7.3

[julienfalque]

Please read the discussion carefully. Each new PHP version might be a BC breaker for PHP CS Fixer so we won't allow it until we do have tests that cover the new syntaxes, which is the main purpose of #3697.

[Cloudmersive]

Still not fixed?

[kubawerlos]

Fixed few months ago.

[stephanvierkant]

I'm using PHP 7.3.4 and I'm getting this error:

PHP needs to be a minimum version of PHP 5.6.0 and maximum version of PHP 7.2.*.

I've installed php-cs-fixer v2.14.2 using composer global. See #4331 for a similar issue, maybe that's your problem too, @Cloudmersive?

[GrahamCampbell]

I've installed php-cs-fixer v2.14.2 using composer global.

It looks like you are not calling the correct version however, or are using a different version of php to what you intended to execute it with.