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

qossmic / deptrac

Keep your architecture clean.

https://qossmic.github.io/deptrac

MIT License

2.59k stars 136 forks source link

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

Closed DanielBadura closed 4 months ago

DanielBadura commented 4 months ago

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 commented 4 months ago

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

Any ideas @gennadigennadigennadi ?

patrickkusebauch commented 4 months ago

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 commented 4 months ago

I update from 2022 to 2023.

EDIT: so next major version, i guess :D

patrickkusebauch commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

DanielBadura commented 4 months ago

But whats with this failing workflow? :D

patrickkusebauch commented 4 months ago

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

gennadigennadigennadi commented 4 months ago

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