Remove stubs from rector.phar

[gnutix]

Would it be possible to remove the stubs/ folder from rector.phar to prevent PHPStorm multiple definition for classes (without having to exclude the whole phar from the project, which is useful to investigate Rectors) ?

[TomasVotruba]

No need to duplicate issue. Send PR right away

[gnutix]

Sorry, I thought you wanted the issue here. I can't provide a fix right now.

[TomasVotruba]

I meant that for future issues.
And PR is always better than idea-issue that can rotten.

Feel free to send PR when ready. Closing as idea is accepted and PR is needed

[gnutix]

Maybe, but having an open issue assigned to me helps me know what I can do when I get time to contribute.

[TomasVotruba]

Without clear dead-line it often rottens. Please don't open it again and just send PR.
Thank you

[gnutix]

Then I'll forget all about it and won't do it... That's what issues are for : listing existing and not yet resolved issues. Then WHEN someone has time and can contribute, he'll fix it (and maybe that'll be me first, and maybe not ! But if the issue doesn't exist in the first place, there's no way it'll be done ever, by no one).

I really don't understand what's your point here... I just know it seriously impedes me wanting to help (as right now, I don't have time anymore to send PR, so the way you close this issue feels to me like "find a way to fix it anyway or fuck off"... and that doesn't feel nice :/). Or else, I have to have my own repo somewhere with issues I create so I don't forget them ? ...

The repo would have hundred or thousands of issues (like some OSS repos do), I might have a clue why you're picky about this... But here? 🤔

[TomasVotruba]

Github issues are not storage for peoples ideas. It should be important to the project, relevant, do-able and the author takes partial responsbility for the task.

I come to many dead open-source projects, buried under dozens or hundreds of similar issues. It's not easy to close them, because the closing person has to withstand the issue creator frustration. So it's left out open and the project slowly dies under pressues of 100 issuse with unclear priority.

The repo would have hundred or thousands of issues (like some OSS repos do), I would think about it. But here? thinking

That's because I invest lot of time to keep it small and focused. This repo had around ~70 issues before Christmass, many of them in similar rotten state. It took lot of work to get under 30 most relevant ones, like bugs, unclear solutions and waiting for PR with test case.

Personally I use paper docs for it, that's place for ideas.

[gnutix]

✔️ Important to the project
See #1899

✔️ Relevant
The problem happens again now that the PHAR is available to all.

✔️ Do-able
It's probably an easy pick.

✔️ The author takes partial responsibility for the task.
Does https://github.com/rectorphp/rector/issues?utf8=%E2%9C%93&q=author%3Agnutix+ looks like tons of rotten issues to you ? I think I'm quite active on this repository, be it by keeping issues alive (reporting details, etc) or by providing fixes (test cases, or even solutions).

So yes, simply said, it hurts having a relevant issue closed just because you think I should "do it in the next 5 minutes". I can't.

[TomasVotruba]

It's probably an easy pick.

Exactly, it could have been already resolved

rector/compiler/build/box.json

Line 13 in 4cbaf5f

"stubs",