[#16289] - [4.0] Class Mapping not detected by PHPStorm
- Closed
- 27 May 2017
- Medium
- Build: staging
- # 16289
Steps to reproduce the issue
PHPStorm and probably other IDEs don't "know" the class mapping from the old to the new namespaces classes (obviously).
Can we do something to make the life easier for developers using an IDE?
I found https://intellij-support.jetbrains.com/hc/en-us/community/posts/207062645--Solved-autoloader-class-mapping-and-phpStorm which suggests to create a file (eg IDE_helps.php) somewhere in the project which contains "bridge definitions" like class JRegistry extends \Joomla\Registry\Registry {}
Expected result
Be able to use code completion and syntax validation also on the "legacy" class names
Actual result
PHPStorm doesn't know the class.
Additional comments
Would that be something we can or should do? Or is there a better way to let IDEs know of our class mapping?
joomla-cms-bot
- | Labels |
Added:
?
|
||
@Bakual I guess this is a reasonable request but should be in another repo (devs or something). It reminds me the way phalcon is handling the absence of all their classes, so I guess we can as well stub all the classes, e.g.: https://github.com/phalcon/phalcon-devtools/blob/master/ide/stubs/Phalcon/acl/Adapter.php
@brianteeman It's valid in that PHPStorm doesn't detect our classmaps. I don't know if there are better solutions today that's why I asked
but should be in another repo
@dgt41 I don't understand?
I would put it into official repo, but exclude it from the distributed package like we do with all the drone, appveyor, travis, composer, and other "helper" stuff. It doesn't matter where it lives, the IDE just has to index it.
No, there isn't a "clean" way to "teach" IDEs about our class mapping. And no, polluting our repo with class stubs shouldn't be the solution here (especially as those would actually register as real classes within the IDE, which may cause unintended side effects when using that for automated code completion/following). It's easy enough for someone to maintain a standalone package away from the main repository (that should actually be preferred, then the bindings aren't locked to the active branch in your local IDE); Laravel had such a thing to help with navigating their Facades, Phalcon apparently has something for that, we don't have to be "special".
It's easy enough for someone to maintain a standalone package away from the main repository
Being realistic, then it will not happen.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-27 19:28:24 |
| Closed_By | ⇒ | Bakual |
It's actually somewhat easy to automate this. Write a quick plugin listening to onAfterInitialise, use Reflection to make JLoader::$classAliases accessible, and loop over the array to create a stubs.php file with the mappings registered in that array. At that point in the request, it should only be the classes we've aliased for core and few (if any) aliases should be registered for extensions.
I don't understand why we could have a generator script in the repo but not the actual file. But thanks anyway.
The mapping file would have to be maintained by hand. At least this way, it is automatically generated and nobody has to manually maintain it.
The script is great. I like that.
My question is why not run the script after something is changed in the classmaps (like we require to run generatecss.php after changing LESS files or running grunt tasks after changing media in J4) and have the stubs.php file in the repo. But yeah, it's not a big issue if I can run the script myself from time to time. It's not like it has to be done on a regular base.
thats a five year post - is it still valid?