6.0 planning

[edsrzf]

I'd be keen to see a bit more of a plan for the 6.0 release. I've only seen comments and PRs here and there that I've pieced together.

Here are the major changes I'm aware of:

• Requiring PHP 8.1+ to run Psalm. (Switch to amp v3 #10024)
• Updating amphp/amp to 3.0. (Switch to amp v3 #10024)
• Updating nikic/php-parser to 5.0. (Update nikic/php-parser to 5.0 #10567)
• A few BC breaks mentioned in UPGRADING.md

Possible other things to consider:

• Drop support for analyzing PHP versions below 7. nikic/php-parser 5.0 has dropped the dedicated parser for PHP 5.x. See its upgrade notes. However maybe it still works well enough that it's worth keeping Psalm analysis. 🤷 I actually can't see any places Psalm checks for versions lower than 7.
• Type pool? Type pool #9328 Or at least the necessary incompatible changes to make a type pool possible.
• Adopt more PHP 8.0/8.1 features (eg promoted constructor properties)

What do we want to be sure to get done before a release? Is there anything else? Is there a timeline to target (aspirational or otherwise)?

[danog]

Personally, the only blockers I see are:

• Allow specifying a custom default template type/begin implementing @satisfies #10577
• WIP: Disjoint keyed array unions #9778

I'm quite busy these days, but I will try to get some work done on those PRs ASAP.

[edsrzf]

No worries, I understand folks are busy. I'm not in any particular rush. I just want to understand what peoples' plans were and look for opportunities to help. Hopefully others will find it useful too.

[Jean85]

Please keep in mind that since only 6.0 will include #10567, this means that:

• Psalm 6 is a blocker to upgrade to PHPUnit 11
• ...and viceversa, so...
• you will need to upgrade to PHPUnit 11 in the same step of upgrading to Psalm

[SCIF]

@Jean85 , in case if you are a user of Psalm then you don't need to install dev-deps of Psalm. The same applies to nikic/parser.

[Jean85]

@SCIF I need PHPUnit for myself, not because it's a dev dependency of Psalm. The only way around that I have is the PHAR, or creating a separate composer.json.

[Jean85]

A simple reproducer is:

$ composer init
$ composer require --dev vimeo/psalm
[...]
Using version ^5.22 for vimeo/psalm
$ composer require --dev phpunit/phpunit ^11 -W

This gets you:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - phpunit/php-code-coverage[11.0.0, ..., 11.0.1] require nikic/php-parser ^5.0 -> found nikic/php-parser[v5.0.0, v5.0.1] but these were not loaded, likely because it conflicts with another require.
    - phpunit/phpunit[11.0.0, ..., 11.0.4] require phpunit/php-code-coverage ^11.0 -> satisfiable by phpunit/php-code-coverage[11.0.0, 11.0.1].
    - Root composer.json requires phpunit/phpunit ^11 -> satisfiable by phpunit/phpunit[11.0.0, ..., 11.0.4].

[edsrzf]

Looks like you're correct that there is a conflict with PHPUnit 11. With that version, phpunit/php-code-coverage has dropped support for nikic/php-parser v4.

You'd need to either stick with PHPUnit 10 for now (which is still supported) or use Psalm from dev-master.

[SCIF]

Thanks, @Jean85 , sorry, I thought the problem is other way round — php-parser requires phpunit 7-9 and that's the issue, but the problem in code-coverage conflicting with php-parser. Clear now.

[SCIF]

Guys, any thoughts on the v6 release? Whether master is v6 branch?

Master is being diverged for a long time and the difference is quite significant. I heavily appreciate all contributions to Psalm and advocate using Psalm a lot. But it looks like the complexity of a contribution to Psalm is sky-high and I worry that the project is slowing down its development. I tried to think about it and came to the following conclusions:

1. A low-hanging fruit is: to eliminate the diverseness of master and current version branches. If master is a next-gen branch then state it in the contribution guide and make the stable branch mergable to master.
2. Put efforts into simplification/refactoring tasks rather than introduction of new features. What I found during the development of my contributions — was a lot of copy-pasted code which is a signal to think about refactoring.

One more time — I didn't want to blame/insult/push anybody but tried to initiate a discussion about the future of this great tool.

[jorgsowa]

I have the same feeling and it's upsetting me. There are many nice features on master and it would be awesome to release it already. For some of the projects, the current version of the psalm is also a blocker for PHPUnit 11.

Are there any things that the community is able to help with? I could allocate some hours myself but without a general direction/timeline/plan it's impossible to know what's expected.

[carlos-granados]

Now that PHPStan 2.0 and Rector 2.0 are both available, both supporting PHP Parser v5 exclusively, it is important to get this Psalm v6 version released. Otherwise it may be difficult for some tools which depend on PHP Parser to support both sets of tools.