Tired of Scrolling Artisan? Meet php artisan list --mine

If you’ve ever run php artisan list and had to scroll past a wall of make:*, migrate, and vendor commands just to find your own, Laravel Artisan List Mine is your new best friend.

https://github.com/CWAscend/laravel-artisan-list-mine

This lightweight Laravel package adds a simple --mine flag to the list command php artisan list so you can instantly filter out all built-in and third-party commands and see only the ones defined in your app.

It works out of the box, just run:

composer require ascend/laravel-artisan-list-mine

It even lets you configure additional namespaces like Domain\ or Modules\ if your project structure goes beyond App\.

Supporting PHP 8.0+ and Laravel 9+, it’s a small quality-of-life upgrade that keeps your terminal focused on what actually matters: your code.

Hope you find this helpful!

Comments

[david duymelinck]

Or you can filter the list based on namespace, for example artisan list -- reports. That comes from the Symfony Console list command.

[Charlie Waddell]

That’s true - namespace filtering is useful when you know how commands are structured.

The goal of --mine is slightly different. It improves DXP in larger and/or unfamiliar projects where you might not know the namespace of custom commands - especially when joining midway through or returning after some time.

It's primarily about discoverability 🙂

[david duymelinck]

Yes they serve two different goals.

I would find it a careless when your library is the only way to know the custom commands.
I would expect tests, documentation, onboarding to give you at least an idea of the custom namespaces that are used.

I agree it is a developer experience upgrade, but I see it more as a redundant feature than an essential one.

[Charlie Waddell]

That’s a process argument. The subject here is developer ergonomics - they’re not mutually exclusive.

Good documentation and onboarding should absolutely exist. This command isn’t intended to replace that. It operates at a different layer by improving discoverability directly within the CLI.

Personally, I can’t read documentation once and retain every namespace structure off by heart - especially in larger projects or when returning after some time away. Namespace filtering is useful when you already know how commands are organised. This removes that prerequisite and surfaces custom commands immediately.

It’s not about necessity, it’s about reducing cognitive overhead and friction in day-to-day use.

Processes and tooling should complement each other.

[david duymelinck]

I agree they are not mutually exclusive. When I mentioned redundant I meant it like backup, not as superfluous.

The goal of the documentation is not needing to know the namespaces or commands by heart. If they are in the documentation, you can search for command( namespace)s.

If you want to stay within the CLI you could do something like.

{
  "scripts": {
    "search-docs": "bash -lc 'term=\"$1\"; grep -R -n -C2 --include=\"*.md\" \"${term}\" docs'"
  }
}

No library required. Not everything needs a PHP solution.
An other option is to use the search of your IDE. Or use an LLM with the documentation or code as context.

[Charlie Waddell]

Scripts, IDE search, or even an LLM can help you find commands - but all of those require searching outside Artisan (or even your terminal if using an IDE). That extra context switching adds friction, especially across multiple projects, for a task this trivial.

You suggest that not everything needs a PHP solution - yet your Bash script only works on Unix-like systems, not Windows (natively). And not everything needs an LLM either - many projects are small or self-contained, where using an LLM would be overkill. If I’m working in Laravel, the natural choice is a PHP-native solution that runs inside Artisan: cross-platform, consistent, and immediately usable.

With php artisan list --mine, you see all custom commands instantly, consistently, directly in the environment where you run them, and without context switching or extra setup (aside from running composer require).

Workarounds like yours exist, but they’re not the same as a seamless, frictionless, cross-platform, integrated CLI experience.

[david duymelinck]

Most people run Laravel in Docker, so just add docker exec to the script and the OS problem is solved.

I see a lot of people that use Laravel, only think in Laravel solutions. I think it is not good to be boxed in like that. Why write code if you can use existing solutions to do the work for you.

[Charlie Waddell]

Most people may run Laravel in Docker, but that still reinforces my point - now you’re adding docker exec into the mix just to search documentation. That’s more indirection for something trivial.

This isn’t about being boxed into Laravel. It’s about reducing friction inside the primary workflow. When I’m working in Laravel, I want to discover and run commands in Laravel - not jump to grep, wrap Docker commands, switch to an IDE search, or involve an LLM.

Generic tools absolutely have their place. But integration matters too. A native Artisan solution isn’t reinventing grep or replacing documentation - it’s improving discoverability inside the environment where those commands actually live and execute.

It’s not about whether alternatives exist. It’s about whether the experience is seamless.

[david duymelinck]

Why would adding Docker be indirection? You mentioned an OS problem. I gave you a solution, another solution is to have a windows and a linux specific script.
Searching documentation is also not the only option, It is possible to search code too.

Are you writing all your code with artisan? Are you accessing databases and API's all the time with artisan? Have you never used tinker? Don't you switch between an editor and a browser a whole bunch of times? Don't you use Vite for frontend code? Don't you use Composer?
Stating that there is a primary workflow and that it is based on artisan is a flawed perspective. You are switching between tools all the time.

I think your library is fine, it is another option people can use.
I'm just asking myself do I want to add more code to my projects. That is why I searched for the namespace option of the list command. I didn't know it existed because I never had a problem with the full list.
I saw the use of only displaying the application commands, and I found several solutions that didn't need to add another dependency.
Coming up with multiple solutions for a single problem is a powerful tool, that allows you to pick the one that suits the needs of projects and the team the best.