-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve type inference for plugin manager implementations #137
Conversation
Signed-off-by: George Steel <[email protected]>
Signed-off-by: George Steel <[email protected]>
Signed-off-by: George Steel <[email protected]>
38af5f4
to
f1499ed
Compare
Just a side-note here: I was about adding this in #98 Therefore, I deferred that to servicemanager v4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - should we 🚢 ?
I think this only applies to our I'd say this is good improvement, and doesn't affect the API per se, just documentation. Downstream consumers that use psalm are used to upgrades "shifting" the types a bit, and will adjust. |
I'm fine with this. Anyways: we need to adjust our own components as well, which are quite a lot. Thinking about:
(btw: with |
I wonder if the installation of renovate (which didn't happen yet, I know, sorry :( ) would already handle this? |
Since I don't think that renovate will create a list of components where the update to the latest |
Well, |
I can create the project to track the progress and to give an overview. |
@froschdesign please do: I just tried creating one, and it messed up everything, possibly because I have 2 versions of GitHub Projects on my system (the pre-release one too) |
Meanwhile, 🚢 here. |
@gsteel @Ocramius @boesing |
Link: laminas/laminas-servicemanager#137 Signed-off-by: George Steel <[email protected]>
Description
Improves type inference particularly for plugin managers in dependent libs