laravel-ide-helper icon indicating copy to clipboard operation
laravel-ide-helper copied to clipboard

Published 20 hours ago • verified publisher icon barryvdh

feat: add separation of tags into groups

Open Kerigard opened this issue 2 years ago • 5 comments

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 https://github.com/barryvdh/laravel-ide-helper/issues/1288

First you need to merge https://github.com/barryvdh/ReflectionDocBlock/pull/8

Type of change

  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [x] 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

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

Kerigard avatar Sep 17 '22 18:09 Kerigard

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

michaeljhopkins avatar Oct 27 '22 18:10 michaeljhopkins

Fine. I'll make changes

Kerigard avatar Feb 25 '23 15:02 Kerigard

@mfn Made changes.

Please check the README file as I used google translate.

Kerigard avatar Feb 26 '23 11:02 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.

Kerigard avatar Feb 27 '23 06:02 Kerigard

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.

mfn avatar Feb 27 '23 07:02 mfn