Update to Symfony 6, PHP-CS-Fixer 3 and PHPUnit 9.5

[Jubeki]

Closes #123

Changed:

• Updated to Symfony\Console ^6.0
• Updated to PHP-CS-Fixer ^3.0
• Updated to PHPUnit ^9.5
  • Rename assertContains to assertStringContainsString
  • Rename assertNotContains to assertStringNotContainsString
  • Rename `assertFileNotExists' to 'assertFileDoesNotExist'
• Updated to PHP ^8.0
• Updated GitHub Actions workflows
• Make constants public (Hook.php)
• Cast shell_exec output to string (src/helpers.php) because trim required a string and not string|ƒalse|null

Added

• Added file_exists check before create a directory

EDIT:
For these wanting to try out these changes you can do the following to your composer.json:

{ "repositories": [ { "type": "git", "url": "https://github.com/Jubeki/composer-git-hooks" } ], "require-dev": { "brainmaestro/composer-git-hooks": "dev-prepare-for-symfony-6" }, "minimum-stability": "dev", "prefer-stable": true }

[NicolasGuilloux]

This makes it incompatible with any other version, and there is apparently no reason to lock it. The same for the PHP version. It would be better to require the following versions :

"require" : { "php": "^7.0 || ^8.0", "symfony/console": "^3.0 || ^4.0 || ^5.0 || ^6.0" } 

It should be obviously tested against any breaking change between versions.

[Jubeki]

I don't agree with you on that.

Most of the version are not supported any more and are only a maintainance burden. Also the old versions will not just stop working and should be mature enough. If you want support for newer version you should update the dependencies as well.

Since this is a breaking change I suggest to tag this also as a new major version 3.0.0 in this case.

To the supported versions:

• PHP-CS-Fixer 2 is longer supported
• PHP-CS-Fxier 3 only supports PHP ^7.4|^8.0
• Symfony 4 and 5 are still being supported, but Symfony 3 is already end of life. For these cases I suggest using an older version of the package.
• Symfony 6 will receive the longest support of all of them and will going forward be the smallest maintenance burden.
• PHP 7.0 - 7.3 are also already end of life and you should consider upgrading to PHP ^7.4|^8.0

[Jubeki]

I think it is the best for the community and in the perspective of security to stay up to date with the maintained packages.

[NicolasGuilloux]

I partially agree about that from my point of view.

• About the outdated version, you're completely right about migrating. It is really bad to have outdated Symfony or PHP running...

• ...but it shouldn't be the maintainer responsibility to force people update their library. If a specific feature is required by a more recent PHP version or symfony console, I agree that the maintener shouldn't bother maintaining for older versions. But if it works, there is no need to lock it. I (very) quickly went through the code, and I don't see anything that justify locking the version.

• About the PHP-CS-Fixer, it is used only for development purpose. I don't agree that it should lock the version in production. The only reason it can block it would be for the CI, that is why PHP CS Fixer in its Readme advice to install it in the tools/php-cs-fixer folder to avoid conflicting with the environment.

• But everything is fine if old versions are still accessible. We can consider that outdated installation won't evolve and therefore, will not need any future fix provided by future updates.

Thanks for the conversation though, I'm always glad to talk about that :)

[Jubeki]

Yeah you are right with the PHP-CS-Fixer. This should only run in the CI or during development.
I also agree with the locking of the versions. Just to say that the current version is already only support Symfony 5 so it might be possible to at least support that version.

In the end the decision lies with @BrainMaestro so he can decide what he wants to support.

[BrainMaestro]

I believe it's fine to update the versions. Users on EOL'd versions of PHP or Symfony Console should use older versions of the package

[rcerljenko]

@BrainMaestro any plans for merging this?

[jdecode]

Can't use this with Laravel 9, until this is approved/merged.

[Jubeki]

@jdecode you can use the workaround I provided in the Pull Request Description.

[jdecode]

@Jubeki - Yes, I am using the workaround for now.
Much thanks for that actually!

And still waiting for PR merge, so that I can upgrade some projects to L9 (without the workaround) 👍

[sirolad]

I am also waiting for this

[eduardoturconi]

I am also waiting for this

[SOSTheBlack]

+1

[AnjaLiebermann]

Can anyone of us do something to speed this up?

[rdgout]

Maybe it's about time to create a fork and move to that. @BrainMaestro doesn't seem to have time to merge a PR that's been opened since january.

[BrainMaestro]

I appreciate the contribution. Sorry for the long wait

[luigel]

@BrainMaestro When will be the new tag for this PR?

[BrainMaestro]

I created a new tag v3.0.0-alpha.1. Check it out and let me know if there are any issues

[RaederDev]

Could you publish a stable, non alpha tag for this?

[TheFox]

I am also waiting for this.

[BrainMaestro]

Sorry for the long wait 😅, but there v3.0.0 now, and I'm able to devote more time to support this project, so it shouldn't take that long between releases anymore