feat: add separation of tags into groups

[Kerigard]

Summary

This PR adds support for the laravel_phpdoc_separation rule for PHPDoc. This feature is disabled by default to avoid problems in existing projects.

Fixes #1288

First you need to merge barryvdh/ReflectionDocBlock#8

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Misc. change (internal, infrastructure, maintenance, etc.)

Checklist

• Existing tests have been adapted and/or new tests have been added
• Add a CHANGELOG.md entry
• Update the README.md
• Code style has been fixed via composer fix-style

[michaeljhopkins]

Would love for this to get merged in. We use Pint in our pipeline and makes ide-helper a bit of a pain

[mfn]

Approach LGTM!

I suggest to:

• fix the merge conflicts
• adapt the tests due to recent changes
• adjust the README to mention the config flag
• rename the config

WDYT?

[Kerigard]

Fine. I'll make changes

[Kerigard]

@mfn Made changes.

Please check the README file as I used google translate.

[mfn]

LGTM, but the I started to question the whole thing why we need to include code style adherence into such a library, wouldn't it make much more sense to adapt the workflow?

Because, yeah well lit may be the official laravel/pint, but people may have different ideas or code styles and it seems just running your style fixer always after any kind of generate ran (also e.g. rector) is simply a requirement?

[mfn]

But reading this, it just occurred to me: does this whole PR even make sense?

Wouldn't it make much more sense to just say:

• well, run ide-helper first
• then your favourite code style fixer

?

It reduces complexity on this library, which shouldn't be much concerned with styling anyway.

WDYT?

[Kerigard]

Not everyone has automated code styling processes set up. In such situations, the user may simply forget to run the linter and push all changes to git.
Also, the user can follow the recommendations for code style without using linters, but then he will have to manually make changes to the models each time.

[mfn]

Not everyone has automated code styling processes set up

I can't argue with that, I don't have numbers to prove it.

But I'm taking a step back and thinking: why add flexibility of code formatting to a library whose goal is not to format the code?

The dedicated tools are there for a reason and are much better equipped to handle this.

My argument is: if someone comes up with the idea he's not satisfied with how this library generates the code "by default", then it is time to think about adding automatic code formatting to your project. It seems backward adjusting libraries when we've the right tools already.

I'm sorry for the forth and back here and time you invested, but from my side, now that I properly understand the intention here, it's 👎🏼 to merge this PR with its current goal.