Skip to content
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

How to handle stubs #2161

Closed
sabbelasichon opened this issue Apr 9, 2021 · 6 comments
Closed

How to handle stubs #2161

sabbelasichon opened this issue Apr 9, 2021 · 6 comments
Assignees
Labels

Comments

@sabbelasichon
Copy link
Owner

The stubs are giving me still a headache. Should they part of the shipped library or not? Sometimes projects using old classes which not exists anymore but should be upgraded to a new class. How to deal with that?

@sabbelasichon sabbelasichon self-assigned this Apr 9, 2021
@sabbelasichon
Copy link
Owner Author

@TomasVotruba The stubs are giving me still headaches.

I need to ship them with typo3-rector because they are needed for old non existing classes in the user codebase.

But they are on the other hand annoying because they get loaded in the IDE and destroy the autocompletion and lead to wrong code analysis. I have renamed them to *.stubs once, but you renamed them to *.php again.

How do you deal with that? I have seen that in the rector-doctrine i.e. example the stubs are not shipped. Don´t really get it, how it works in a user codebase where old files do not exist anymore but are still referenced in the code.

@TomasVotruba
Copy link
Contributor

Ah, I've missed this.

Well, the stubs are not shipped with package, as the users' code base includes them already.
E.g. people who use Doctrine rules already have a codebase with Doctrine packages.

Do you maybe have an exmple where missing stubs fail?

@sabbelasichon
Copy link
Owner Author

I can give you a real life example from TYPO3. In TYPO3 9 we have used swiftmailer with i.e. classes like Swift_Image but in version TYPO3 10 we are using Symfony Mailer and Mime. If you upgrade to version 10 and run rector afterwards you don´t have the swiftmailer classes anymore and the rector fails. Is this understandable?

@TomasVotruba
Copy link
Contributor

In theory yes. I wonder if we can make it work somehow without stubs. After all, it's only class rename, there should not be a need for any reflection.

Could you make a simple reproducible failing test case in Rector? I'll try to figure a way to make it work without reflection

@sabbelasichon
Copy link
Owner Author

@TomasVotruba It is now working statically without invoking the autoloader for the ClassRenaming part.
Basically the missing part was this one: c924f8c#diff-5d6f21616131ebbf56ab692f8d9f7cef73b1c7167c5a33e8fd7bc8262cb3a2c5R4

@TomasVotruba
Copy link
Contributor

I see. Replacing dynamic reflection with static 👍

In Rector we basically followed steps of this issue:
rectorphp/rector#5906

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants