Arbitrary types map

ColinMollenhour

A feature that would be immensely useful for my team and other teams and projects still using PhpStorm is support for the PhpStorm-invented "arbitrary types map". We generate this file in our project and it contains hundreds of entries. This would make switching the team over to VS Code so much easier. We'd be happy to pay for Premium licenses if this feature was included.

Also, if there is an alternative that already works where we could achieve the same, please let me know.

Here is an example snippet:

<?php
namespace PHPSTORM_META {
    override(\Mage::getModel(), map([
        'admin/acl' => \Mage_Admin_Model_Acl::class,
        'admin/redirectpolicy' => \Mage_Admin_Model_Redirectpolicy::class,
        'admin/role' => \Mage_Admin_Model_Role::class,
        'admin/user' => \Mage_Admin_Model_User::class,

From a quick search, there are hundreds of other projects that use this feature:
https://github.com/search?q=.phpstorm.meta.php&type=issues

Examples:

OpenMage/Maho Commerce/ Magento 1: https://github.com/OpenMage/magento-lts/tree/main/.phpstorm.meta.php
Typo3: https://github.com/alexanderschnitzler/phpstorm.meta.php-typo3
Nette: https://github.com/nette/di/blob/master/.phpstorm.meta.php
SilverStripe: https://github.com/silverstripe/silverstripe-framework/issues/9658
PHP Github API Client: https://github.com/KnpLabs/php-github-api/issues/1092

Thanks for your consideration!

ColinMollenhour

ColinMollenhour
Ahh, lol, I just saw I had problems with this last year and opened an issue about it.. :D

Apparently DEVSENSE PHP does support this file, but it appears to not be working for me:

ColinMollenhour

Not sure if it matters but I added "0" as the first argument and the type inference is working now, but I'm still getting errors because it's inferring a method of the same name but from a different class that it should not be inferring. No idea how it is suggesting MWE_Core_Model_Queue in this case, is that a feature that can be disabled so it only infers types that have a direct connection?

(in red is the wrong class - no relation, in green is the correct class based on the metadata file)

JakubMisek

@ColinMollenhour, thank you for pointing this out.

It is supported, but the format changed recently - we'll try to update the support in the next update.

Not sure, why it got MWE_Core_Model_Queue in your case; May I ask to try the following, and check the tooltip of the assigned variable $test?

$test = Mage::singleton('stock/movement_collector');

ColinMollenhour

It gets the correct type - the reason for the Mage_Core_Model_Abstract is that is the @return type of the getSingleton method.

JakubMisek

ColinMollenhour thanks, is the Mage_Core_Model_Abstract a parent of MWE_Core_Model_Queue ? (we may be searching too far in this case)

ColinMollenhour

JakubMisek Yes, in this framework just about every model (hundreds) are subclasses of Mage_Core_Model_Abstract. There are only three others that have an "add" method, so not sure why it's picking this specific one. I changed the @return for getSingleton to just "mixed" and that does seem to fix it.

I'd still possibly consider this a bug, although I don't know if fixing it would be taking away other useful functionality.. Is this automatic inference a feature flag?

JakubMisek

ColinMollenhour thanks, I thought so;

It is a kind of bug that "workarounds" issues with various purely annotated frameworks. But it can be done better. I'll take a look on it!

JakubMisek

The latest release 1.59.17674 fixes this case.

Please open a new issue if there is something else :)

Thanks!