New Classifiers

[gmgarrison]

Hello! Love the package but I found a few parts of my application that weren't counted. Would you consider including:

• Eloquent Builders (App\Builders, subclass of Illuminate\Database\Eloquent\Builder)
• Enums (App\Enums, isEnum() is true)
• Filament Resources (App\Filament\Resources, subclass of Filament\Resources\Resource)
• Services (App\Services, these are just generic PHP classes so you might just have to check the namespace?)
• View Components (App\View\Components, subclass of Illuminate\View\Component)

I tried my hand at writing them up and I'm happy to share if you're interested.

Thank you either way!!

[stefanzweifel]

Thanks for the suggestion.

I think Eloquent Builder and View Component classifiers would fit great into this package right now.
Feel free to send in a PR for this.

I think Services is just too generic and such a classifier probably lives best in your project or a separate package.

Enums I'm not sure honestly. Kinda like the idea to see the number of Enums a project has. 🤔

[gmgarrison]

Thank you for responding!! Glad we're on the same page for Builders and Components.

I'm not sure I understand the argument that Services is too broad - how does that mean that those lines of code shouldn't be counted in a project? It's not something that gets filled with boilerplate by any package or automated code production utility as far as I can tell. It's also definitely a legitimate pattern that's getting some adoption:

• https://medium.com/@laravelprotips/understanding-laravel-service-classes-a-comprehensive-guide-1f22310c70bd
• https://laraveldaily.com/post/service-classes-laravel-open-source-examples
• https://medium.com/@zulfikarditya/how-to-use-service-classes-in-laravel-12-for-a-clean-and-maintainable-codebase-8dcad19bec72
• https://medium.com/@sliusarchyn/service-layer-in-laravel-use-it-ae861fb0f124

I do agree that it's broad but that doesn't feel like an argument to exclude lines of code in a project-based count, especially if people are explicitly collecting business logic in those classes (as I am).

Finally, you didn't respond to the Filament question. I can understand that it's not a simple question... there's a lot of boilerplate code with Filament resources but it's also got a HUGE adoption in the wild and ignoring it seems like a miss. How are you thinking about it? You've already got a Nova Classifier and my impression is that Filament has taken over from Nova for any new projects and is working its way through legacy projects.

I'll end with another thanks - I love the open source community and if I get to contribute a PR this would be my first PR in the wild. I am happy to support a community that is open to discussion and wants to do great things. It's a tiny slice of the world that we can take joy in. :)

[stefanzweifel]

Sorry for not communicating more clearly. Work currently consumes all my energy and I didn't invest too much time into my reply yesterday.

On Services:

I'm aware of the concept of Services and use them in some of my projects as well. I think adding a classifier for Services to the project is not the right way, as a Service-class is hard to detect for a package like this.

All those tutorials assume such a class lives in App\Services. So would a classifier just look if a class is inside this exact namespace? (Not App\Services\Feature or App\Domain\FeatureX\Services).
Does a Service class need to extend a specific class or implement a certain interface?

Personally, I've never created a service class in App\Services but rather deep in a Domain-folder like App\Domain\Billing\CreditCardPaymentService.

That's why I said "services are too broad". The usage and location of such Service classes just differs too much from project to project and from team to team, that I don't see a neat way how we can solve this in laravel-stats.

On Filament:

I simply forgot to mention that. This definitely makes sense. I'm a heavy user of Filament and basically build all my apps with it now.
I think we could start with classifiers for:

• Resources
• Pages
• Widgets

We could spin this endlessly and also list custom Infolist-, Table- or Form-components.

---

Side Note: For a long time I also wanted to start a complete rewrite of the package using something like https://github.com/spatie/php-structure-discoverer. The current approach of the package doesn't allow to discover Pest-test for example. 🙃

[gmgarrison]

No need to apologize!!

You're right that "Services" live in lots of places and doesn't usually (ever?) extend a given class or implement an interface. On the other hand, I know first-hand that when I refactor, one of the main things I'm thinking about is what's reusable and needs to get moved into a Service class so it would be great to be able to include that in a lines-of-code count.

What if there was a config option to just include custom namespaces? It could be used for Services or any other code pattern that doesn't fall into an existing Classifier. I'm thinking it would just take an array of strings to be treated as namespaces. Does that feel satisfying at all?

And we're on exactly the same page with Filament.

I looked at the Spatie package you linked but most of it over my head, TBH. I know enough to know that Spatie packages are generally great so my default would be to try to leverage that if possible, but I also know enough to know that "complete rewrite" doesn't sound like fun. :)

[stefanzweifel]

What if there was a config option to just include custom namespaces? It could be used for Services or any other code pattern that doesn't fall into an existing Classifier. I'm thinking it would just take an array of strings to be treated as namespaces. Does that feel satisfying at all?

There's already such a config. You can create custom classifiers to detect your own "components" like a Service class or whatever else works for your project.
https://github.com/stefanzweifel/laravel-stats#create-your-own-classifiers

In one of my work projects, we have a huge number of "Configuration"-classes for a specific feature. We've created custom LaravelStatsClassifiers so they show up in the command output.