Upgrade PHP engine from 8.3 to 8.4

[llaville]

Is your feature request related to a problem? Please describe.
Upgrade default PHP engine from 8.3 to 8.4

As it now available on Alpine Linux Packages : see https://pkgs.alpinelinux.org/packages?name=php84&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer=

Describe the solution you'd like
Upgrade https://github.com/oxsecurity/megalinter/blob/main/megalinter/descriptors/php.megalinter-descriptor.yml

I can suggest a PR

Describe alternatives you've considered
No alternative exists, except if we keep on PHP 8.3

[llaville]

We have still to wait ... :( Available only on edge branch and not on v3.20

[echoix]

I just saw that alpine 3.21 was released today https://www.phoronix.com/news/Alpine-Linux-3.21

[nvuillam]

@llaville you are the PHP master here, we wait for your PR :)

[llaville]

I just saw that alpine 3.21 was released today https://www.phoronix.com/news/Alpine-Linux-3.21

@echoix Thanks for this notification !

[llaville]

@nvuillam As we are PHP 8.4 available on Alpine Linux v3.21 (https://pkgs.alpinelinux.org/packages?name=php84&branch=v3.21&repo=&arch=x86_64&origin=&flagged=&maintainer=) I'll prepare a PR today !

Afraid that we are to wait again, because Python 3 is not yet available on v3.21

oh yes https://pkgs.alpinelinux.org/packages?name=python3&branch=v3.21&repo=&arch=&origin=&flagged=&maintainer= but not on previous x86, x86_64 architecture

ERROR: failed to solve: python:3.12.7-alpine3.21: docker.io/library/python:3.12.7-alpine3.21: not found

[llaville]

Trying directly with Docker image : https://hub.docker.com/_/php/tags?name=8.4.1-cli-alpine3.20

[llaville]

I've been able to build a MegaLinter docker image with previous PHP 8.4.1 Alpine 3.20.

I'll keep you aware when all my regression tests will be over. And if OK a PR will follows

[llaville]

Tip

For PHPStan user audience

As MegaLinter v8.2+ support now only PHPStan 2.0, if you have a project than raise no errors with PHPStan 1.12, I recommend to disable PHPStan error to avoid your CI to fails.

To do so: add this entry in your MegaLinter config file

PHP_PHPSTAN_DISABLE_ERRORS: true

[llaville]

Tip

For Psalm user audience

As MegaLinter v8.2+ support only Psalm 5.26.x, (that is not yet PHP 8.4 compatible), I recommend to disable Psalm linter to avoid your CI to fails.

To do so: add this entry in your MegaLinter config file

DISABLE_LINTERS:
  - PHP_PSALM

[nvuillam]

@llaville plz can u add the tips in related linter descriptir linter_text property ? :) (it handles markdown ^^)

[echoix]

For the PR, maybe just watch and wait until a Python docker image with the same Python version is published. Renovate probably won't help, as it is like two kinds of versions in the same tag, and I didn't configure it precisely enough for that. I think there's some failures with Python 3.13 still

[llaville]

@echoix You've probably right : we have to wait that all elements are available, because

But no Docker image python:3.12.8-alpine3.21 (at hour I write these lines) available.
So this morning, while I still have free time, I'll continue my test on alternative solution that seems to work good !

[llaville]

Related to my previous tip #4351 (comment) about Psalm, I don't think so that the project team will support PHP 8.4 in a reasonable timeframe.

Especialliy also because Psalm v6.0 is more a dream than a beginning of reality (and no PHP 8.4 is provided too)

My question to MegaLinter Core team:
If you don't have noticed yet, I'm not a big fan of Psalm, but as this linter is officially supported by ML, do we

1. add just a note about PHP 8.4 incompatibility
2. add an alternative by supporting both PHP 8.3 and 8.4 engine in next MegaLinter feature release

[nvuillam]

What is your preferred option ? (you are the PHP MegaLinter Core Team :D )

My main concern is to remain compliant with the more users possible, and to avoid breaking changes when we create new MegaLinter versions ^^

[llaville]

@nvuillam I've tried to install Psalm 5.26 on a PHP 8.4 platform, but cannot removed DEPRECATIONS raised by new PHP 8.4 engine.

All PHP users should know how to disable it

Tip

With E_ALL = 32767 and E_DEPRECATED = 8192

php -d error_reporting=24575 vendor/bin/psalm

But in case of Psalm, it won't work because they disalowed this behaviour at https://github.com/vimeo/psalm/blob/5.26.1/src/Psalm/Internal/ErrorHandler.php#L62

So, even if we can install Psalm 5.26 on PHP 8.4 (with composer require --dev vimeo/psalm --ignore-platform-req=php ), deprecations will still be alive and will breaks Psalm results.

Other alternative is to embed both PHP 8.3 and 8.4 engine.
But even if we already did it in past, it was to suuport all PHP linters, and not just one. So I don't like this approach.

If we won't let Psalm Users behind, we have no choice than to tell us to use MegaLinter until a version (8.3.0 is the latest at day of today) that suuport PHP 8.3

WDYT ?

[nvuillam]

I'm afraid that making MegaLinter even heavier just for a linter is maybe not such a good idea :/

How is PHP 8.4 adoption ? Can't we wait that psalm becomes compliant with it before upgrading PHP in MegaLinter ?

[llaville]

I'm afraid that making MegaLinter even heavier just for a linter is maybe not such a good idea :/

👍

How is PHP 8.4 adoption ? Can't we wait that psalm becomes compliant with it before upgrading PHP in MegaLinter ?

PHP 8.4 is planned since a long time, and even if projects like mine migrated to them lately, there are no really BC breaks that should stop adoption.

When I have a look on projects that have already adopted PHP 8.4, there are no so much changes or difficulty to do so !
Only one or two deprecations categories (see https://php.watch/versions/8.4#deprecations), and the main one is well explained at https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated

Of course we can wait Psalm adopt it, but are there are no clearly roadmap, we don't know how much time !

[llaville]

I will suspend my works on it ... until next year, and I hope it will come with good news ;-)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[llaville]

I suspect we will wait a long ... long time before Psalm support PHP 8.4
A beginning of answer that confirm my hypothesis : teapot-php/status-code#167 (comment)

[echoix]

I think you're right that we can't be waiting forever for some packages that might never be updated

[llaville]

To all MegaLinter team: I've a good and bad news.

First, begins with the GOOD one:

• Nothing is impossible, and nobody should give up, because I've been able to run Psalm on a Docker Container that have only PHP 8.4 runtime defined (I'll explain it later)

Now the BAD news :

• I've not been able to build the PHP flavor https://github.com/oxsecurity/megalinter/blob/main/flavors/php/Dockerfile at least locally with python:3.12.8-alpine3.21 (error summary : "Building wheel for datrie (pyproject.toml) did not run successfully.")

While in same time, with python:3.12.8-alpine3.21 I've been able to build single linter Dockerfile, like :

• https://github.com/oxsecurity/megalinter/blob/main/linters/php_psalm/Dockerfile
• https://github.com/oxsecurity/megalinter/blob/main/linters/php_phplint/Dockerfile

Because the solution (purely Composer based) to run Psalm with PHP 8.4 runtime is really pretty cool, and we don't have to wait a Psalm compatible version (v5.26.1 works fine), I hope that the PR I'll propose soon will be run successflully and CI will be able to build MegaLinter Dockerfiles.

More info, and PR will come very soon ...

[nvuillam]

@llaville thanks again for being the PHP soul of MegaLinter 🥇

[llaville]

Even if more and more PHP projects begun to drop Psalm in favor of PHPStan :

Recent ones:

• https://github.com/doctrine/dbal/releases/tag/3.9.4
• https://github.com/VincentLanglet/Twig-CS-Fixer/releases/tag/3.5.1

We still give it a possibility to run Psalm 5.26 on PHP 8.4 runtime with commit e1eea9b (thanks to Composer platform setting to allow it).

PHP 8.4 runtime was upgraded by commit c29b7f9

[llaville]

PR 4517 raised a SPELL lychee error. Is somebody in ML team has a fix (in queue) for that please ?

[llaville]

Strange because PR ML bot #4517 (comment) raise a warning ;-)

[nvuillam]

PR 4517 raised a SPELL lychee error. Is somebody in ML team has a fix (in queue) for that please ?

Just run again the job, it must be a temporary outage :)

[llaville]

@nvuillam You're right.
BTW I've other strange regressions (see PHP CS Fixer) : I'll check it later this afternoon.

[llaville]

Ok found origin of issue with PHP-CS-Fixer.

Natively, latest version 3.68.1 accept PHP 8.4 as constraint https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/v3.68.1/composer.json#L23 and so can be installed on a PHP 8.4 platform.

But, PHP 8.4 is not officially yet supported by project (see PHP-CS-Fixer/PHP-CS-Fixer#8298)

And when we run MegaLinter tests we can see it (the answer into logs).

Following Contribution Guide, here are the procedure to test it (with the quick fix to make tests PASSED)

docker buildx build -f linters/php_phpcsfixer/Dockerfile . --tag php_phpcsfixer --secret id=GITHUB_TOKEN,env=GITHUB_TOKEN
TEST_KEYWORDS_TO_USE="php_phpcsfixer"
docker run -e PHP_CS_FIXER_IGNORE_ENV=true -e TEST_CASE_RUN=true -e OUTPUT_DETAIL=detailed -e TEST_KEYWORDS="${TEST_KEYWORDS_TO_USE}" -e MEGALINTER_VOLUME_ROOT="." -v "/var/run/docker.sock:/var/run/docker.sock:rw" -v $(pwd):/tmp/lint php_phpcsfixer

And we could see expected results :

Skipped setting git safe.directory DEFAULT_WORKSPACE:  ...
Setting git safe.directory default: /github/workspace ...
Setting git safe.directory to /tmp/lint ...
[MegaLinter init] RUNNING TEST CASES

... more ...

============================== slowest durations ===============================
2.59s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_failure
1.93s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_get_linter_version
1.35s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_success
0.39s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_get_linter_help
0.05s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_format_fix
0.03s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_report_tap
0.03s call     megalinter/tests/test_megalinter/linters/php_phpcsfixer_test.py::php_phpcsfixer_test::test_report_sarif

(14 durations < 0.005s hidden.  Use -vv to show these durations.)
================== 4 passed, 3 skipped, 6 warnings in 10.89s ===================
Pytest exited 0
Successfully executed Pytest 

Where is the best place to set environment variable PHP_CS_FIXER_IGNORE_ENV=true on MegaLinter test workflow ? @nvuillam

[llaville]

[nvuillam]

@llaville in the descriptor, in the install -> dockerfile property :)

Example:

megalinter/megalinter/descriptors/java.megalinter-descriptor.yml

Line 11 in e4a07af

dockerfile:

[llaville]

@nvuillam Thanks. Update was added 236fbc2.

Waiting now for CI results .... cross fingers ;-)

[llaville]

CI failed but I don't understand why it blocked !

With branch main...toPhp84 and 6 commits

I've rebuild and test Docker container and got no error

[echoix]

When building and a commit is made by a bot using the GITHUB_TOKEN, the workflows don't run. It prevents infinite loops. It's a GitHub limitation. Close and reopen the PR, add a commit made by a human, or anything that triggers a synchronize event. I closed and reopened one of your PRs since CI didn't start. But maybe you continued after.

[llaville]

I think there is a problem with automation when retreiving some package, especially PHP-CS-Fixer

On branch toPhp84 I got this diff

diff --git a/.automation/generated/linter-helps.json b/.automation/generated/linter-helps.json
index 558328194f..24f91cb16f 100644
--- a/.automation/generated/linter-helps.json
+++ b/.automation/generated/linter-helps.json
@@ -4493,6 +4493,9 @@
         ""
     ],
     "php-cs-fixer": [
+        "PHP needs to be a minimum version of PHP 7.4.0 and maximum version of PHP 8.3.*.",
+        "Current PHP version: 8.4.2.",
+        "Ignoring environment requirements because `PHP_CS_FIXER_IGNORE_ENV` is set. Execution may be unstable.",
         "Description:",
         "  List commands",
         "",
diff --git a/.automation/generated/linter-versions.json b/.automation/generated/linter-versions.json
index 8c4e2dae45..eefcdfb7b0 100644
--- a/.automation/generated/linter-versions.json
+++ b/.automation/generated/linter-versions.json
@@ -63,7 +63,7 @@
     "npm-package-json-lint": "8.0.0",
     "perlcritic": "1.156",
     "php": "7.4.26",
-    "php-cs-fixer": "3.68.0",
+    "php-cs-fixer": "7.4.0",
     "phpcs": "3.11.2",
     "phplint": "9.5.6",
     "phpstan": "2.1.1",
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 908d077ae7..325734da1c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -203,6 +203,7 @@ Note: Can be used with `oxsecurity/megalinter@beta` in your GitHub Action mega-l
   - [tflint](https://github.com/terraform-linters/tflint) from 0.54.0 to **0.55.0** on 2025-01-17
   - [xmllint](https://gitlab.gnome.org/GNOME/libxml2/-/wikis/home) from 21207 to **21304** on 2025-01-17
   - [lightning-flow-scanner](https://github.com/Lightning-Flow-Scanner) from 2.36.0 to **2.37.0** on 2025-01-17
+  - [php-cs-fixer](https://cs.symfony.com/) from 3.68.0 to **7.4.0** on 2025-01-17
 <!-- linter-versions-end -->

 ## [v8.3.0] - 2024-11-23

But version 7.4.0 does not exists. Latest version available is only 3.68.1

[llaville]

I'll try with a new branch and applying only 5 essential commits !

[llaville]

No new PR, but building is in progress : https://github.com/oxsecurity/megalinter/actions?query=branch%3AtoPhp84_v2

[llaville]

Essential content are only 4 commits : main...toPhp84_v2

[llaville]

All is ok now with new branch

[nvuillam]

Usually when

When building and a commit is made by a bot using the GITHUB_TOKEN, the workflows don't run. It prevents infinite loops. It's a GitHub limitation. Close and reopen the PR, add a commit made by a human, or anything that triggers a synchronize event. I closed and reopened one of your PRs since CI didn't start. But maybe you continued after.

Usually I just update the comment of MegaLinter auto-fix commit, then force push to launch again the job :)

[llaville]

toPhp84_v2 branch are ready for ultimate code review : https://github.com/oxsecurity/megalinter/actions/runs/12841378520

As it seems I'm not able to re-open PR #4518 I've closed myself, I'll open a new one

[llaville]

@nvuillam / @echoix As you've perharps noticed (like me) MegaLinter 8.4.0 embedded Psalm v6.0 (just been released) that support natively PHP 8.4 runtime.

So my fix at https://github.com/oxsecurity/megalinter/blob/v8.4.0/megalinter/descriptors/php.megalinter-descriptor.yml#L137
can be simplified by removing composer config --global platform.php 8.3

Even if it will continue to work like this, it may be clarify php descriptor file.

Oh and also BTW, I've noticed that on https://github.com/oxsecurity/megalinter/releases/tag/v8.4.0 we still see invalid version fro PHP-CS-Fixer already mentioned at #4519 (review)

[nvuillam]

@llaville thanks for noticing the issues, we'll be glad to merge your PRs :)

[llaville]

@llaville thanks for noticing the issues, we'll be glad to merge your PRs :)

On way with new 328e159 commit