phpstorm.meta.php support for dynamic return types #2219
Conversation
… it up to the lazy return type extension provider to generate extension services dynamically
| @@ -219,6 +219,9 @@ parameters: | |||
| editorUrlTitle: null | |||
| errorFormat: null | |||
| __validate: true | |||
| phpStormMeta: | |||
| metaPaths: | |||
| - '.phpstorm.meta.php' | |||
There was a problem hiding this comment.
What does this path mean?
- How does PhpStorm search for these files? Can they always be expected to be alongside composer.json?
- Is the file always named the same?
I'm clinging towards only looking at the project file for now, I've never seen a public package to include this file.
There was a problem hiding this comment.
here's an example of one in mockery/mockery
https://github.com/mockery/mockery/blob/master/.phpstorm.meta.php
There was a problem hiding this comment.
According to PHPStorm’s documentation (link), I would say it scans the entire project for files and directories with this name, and parses them all. This implementation only looks for it next to composer.json, but that is not the only place where PHPStorm would look.
I found the following packages with this file in my projects: nesbot/carbon, phpunit/phpunit, mockery/mockery, league/commonmark, nette/di, nette/utils. There are also several files with this name inside jetbrains/phpstorm-stubs, and there’s thomas-schulz/symfony-meta that provides these definitions for various Symfony components.
I think that searching the entire project (or at least vendor/) would give the closest experience to PHPStorm. But I can see arguments against this search as well, e.g. performance, metadata conflict resolution.
There was a problem hiding this comment.
I think the way forward is to describe behaviour with advanced PHPDoc features which there are plenty of already, and PhpStorm starts supporting them too. That's why I think we don't need to look in vendor.
I think we should look for these files in %composerAutoloaderProjectPaths%. These are the paths where PHPStan looks for composer.json files.
Also, to be honest - I'm not sure I want to merge and maintain these 800 lines of code if the decided way forward for the community is advanced and already implemented PHPDoc features like conditional types, assert tags etc.
Maybe I can give you the needed hooks so that you can register these extensions in your own package instead?
Thank you for understanding.
There was a problem hiding this comment.
Yes, I can see your reasoning about leaving this out. Adding a hook in LazyDynamicReturnTypeExtensionRegistryProvider to register these extensions would be enough, then I could leave this in a separate package. Even without such a hook, a separate package would still work, the users would just have to declare those extensions manually.
This PR starts to add support for PHPStorm’s metadata files. It only supports a few basic directives for resolving method/function return types, but of course support for other directives can be added.
I do not think this is ready for a merge yet, I would like some feedback before I dig deeper into it. For example:
registerArgumentsSet)?