Auto import Nextcloud classes in rector runs #48371
Conversation
We skip all files outside of OC/OCA/OCP from "use" auto-import because it’s not always desirable to import classes when they have generic names, so it should be the developer choice. Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
come-nc
requested review from
ChristophWurst,
miaulalala,
nickvergessen,
st3iny and
tcitworld
as code owners
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Psalm found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
|
|
||
| $nextcloudDir = dirname(__DIR__); | ||
|
|
||
| class NextcloudNamespaceSkipVoter implements ClassNameImportSkipVoterInterface { |
There was a problem hiding this comment.
This should go into nextcloud/rector then?
There was a problem hiding this comment.
It could, yeah.
The thing is we cannot make it configurable, because it’s added as a service by class name only.
But if it stays general like this we can put in nextcloud/rector, yes. Also we can make it extendable with a protected property to override if needed.
Do you have examples in mind so that we can look if there is a pattern we could apply?
That is quite hard to implement I think. The SkipVoter which avoid use conflict is based on the already imported use list: https://github.com/rectorphp/rector/blob/main/rules/CodingStyle/ClassNameImport/ClassNameImportSkipVoter/UsesClassNameImportSkipVoter.php |
| $server->addPlugin(new \OCA\DAV\CalDAV\Schedule\Plugin(\OC::$server->getConfig(), \OC::$server->get(LoggerInterface::class), \OC::$server->get(DefaultCalendarValidator::class))); | ||
| $server->addPlugin(new Plugin(\OC::$server->getConfig(), \OC::$server->get(LoggerInterface::class), \OC::$server->get(DefaultCalendarValidator::class))); |
There was a problem hiding this comment.
For example here it would be better to use the fqn as Plugin is a very generic name.
Same thing goes for the IManager classes. For those it would be nice to either use the fqn or at least the part before that so it is Group\IManager and so on.
Maybe this is not so bad, but to me it seems harder to read the code and easier to make mistakes when changing imports.
|
Could we maybe limit this to a few classes like \OCP\Server and \OCP\Util for now? I don't know how many other cases we have where this happens a lot. |
My problem is this rule set: https://github.com/nextcloud-libraries/rector/blob/8061985c44798bac1657ba5bc2d6efa5b10e9089/config/nextcloud-25/nextcloud-25-deprecations.php#L17 |
Summary
When using rector, fully qualified names are often outputted by the rules, like
\OCP\Serveror\OCP\Http\Client\IClientService. To avoid that, one can usewithImportNames()to tell rector to import names with use statements, but then it will import all names.This is not always desirable, for instance
\LDAP\Connectionin user_ldap would be confusing because there is an\OCA\User_LDAP\Connectionclass as well.So I added a custom "SkipVoter" which skips auto-import for all classes outside of OC/OCA/OCP.
It may still be a bit confusing for common names like IManager, but I think we can live with that? Or I can add other exceptions if needed.
Note that rector is smart enough to not import two classes with the same name, but it will randomly import one of them and keep the fully qualified name for the other one.
I’m doing that so that when we apply Nextcloud rules set later we do not get fully qualified names everywhere but nice use statements instead.
Checklist