Update jetbrains/phpstorm-stubs from 2022.2 to 2023.3 as minimal version

[DanielBadura]

Due to not having an up to date shim version and instead needing to require this repository as no other solution is there at this moment, see here #1345, this package is blocking from installing it alongside other packages.

[DanielBadura]

Not sure why the Composer Diff workflow is crashing. composer.lock is still there and also updated 🤔

Any ideas @gennadigennadigennadi ?

[patrickkusebauch]

Doesn't your change make it stricter? AIIRC the original let's you install either 2022.2 or 2022.3 and your change will let you install only 2022.3. Am I missing something?

[DanielBadura]

I update from 2022 to 2023.

EDIT: so next major version, i guess :D

[patrickkusebauch]

Apparently I am missing that I am blind. If the intention is to enable to install either version, can we specify it as such in the version constraint?

[DanielBadura]

The goal was not to enable either version but to update from my pov.

I'm not sure, if allowing both versions is desired here. These are stubs, so only adding some more/better meta information so imho it just should be the newest version. BUT im not sure where this is used here and why tbh. But can also adjust the require to allow both versions.

[patrickkusebauch]

My reasoning is as follows:

• You don't use the shim/phar version because it did not release in a long time but use the source directly. This is something others are likely to do as well (for example I do this too)
• You have a conflict with ^2022.2 in your source and therefore want ^2023.3.
• We upgrade to ^2023.3
• Others will have a conflict with ^2023.3 because they need ^2022.2 for the same reason as you need ^2023.3
• If we upgrade to ^2022.2 || ^2023.3, it enables both you an others. It will install what is allowed and needed by other requirements, but preferring the newer version.

My intention is to not break stuff for others while fixing it for you.

[DanielBadura]

I know where you are coming from, but imho it should not be a real issue. They could also update, since updating this dependency should not really break anything (bold statement, i know). But i can change it - no problem.

But as you already said. The main reason is the not available releases and because of that such updates are cumbersome.

[patrickkusebauch]

👍 LGTM

[DanielBadura]

But whats with this failing workflow? :D

[patrickkusebauch]

Don't worry about it. If fails anytime somebody from a fork updates composer.lock.

[gennadigennadigennadi]

@DanielBadura thank you for your contribution and your patience 😅.