[11.x] Support Single and Multi-Selection for Publishing Stubs

[ahinkle]

This PR adds support for single and multi-selection using Laravel Prompts in the stub:publish artisan command.

Screen.Recording.2024-12-04.at.10.43.23.AM.mov

The stub:publish command currently publishes all customizable stubs, which now includes 52 stubs. With this change, it adds flexibility for developers who only need to customize a few specific stubs.

• You can now choose which stubs to publish directly from a selection menu, making it easier to target just the stubs you need.

• --all Option: If you prefer to publish everything, the --all flag skips the menu and works just like it does today.

Examples:

Interactive Mode:

Simply run:

php artisan stub:publish

and select one or more stubs from the list:

End Result:

Publish All:

Use the --all flag to publish everything at once:

php artisan stub:publish --all

[taylorotwell]

I think we should limit this prompt to the most commonly customized stubs and give them human friendly names rather than file names. 👍

[ahinkle]

Thanks! Made a few updates.

• I updated the names to be more human-readable. After reviewing, I realized that reading the names left to right didn’t feel natural. Leading with the secondary descriptor (e.g., "Invokable Controller" instead of "Controller Invokable") makes them easier to understand.

• I reviewed our laravel apps to find the most commonly used stubs and narrowed the list to focus on essentials. Models, controllers, migrations, seeders, factories, tests (+ Pest), resources, notifications, mailables, and jobs. This reduced the list from 52 to 31 stubs. I’d love to hear your thoughts on whether this selection feels right or needs some adjustments.

• Since we’re now focusing on common stubs, what do you think about adding a --list-all flag to show the full list of available stubs? This could be useful for developers looking for less common ones.

[taylorotwell]

Couple of notes here... I think things like Controllers should probably be grouped like

• Controller
• Controller (Invokable)
• Controller (API)

That being said, the amount of controller stubs we have makes me sad and makes the menu feel a bit confusing 🥲 ... not sure what to do about that. There would be 12 entries just for controllers.

[ahinkle]

Thanks! I completely understand your concerns about the number of stubs and the potential confusion in the menu. I’ve been thinking about ways to address this and wanted to reach out to the community for feedback on a balance between flexibility and simplicity, but I haven’t landed on a solid solution yet. Here are a few ideas I’ve been considering:

• Grouping by categories: For example, having a single "Controllers" menu item that opens a sub-menu for specific types like "Standard," "Invokable," and "API." This could reduce clutter but might slow down developers wanting to move quickly.

• Reducing the number of stubs: Are there some stubs we can safely remove or merge without negatively impacting developer experience? Likely overkill for a console improvement

• Dynamic or searchable menus: Allow users to type and filter stub names dynamically, especially as the number of options grows over time? I currently have this implemented but it can come across as overwhelming, especially to newcomers.

I’d love to hear the thoughts of others in the community. If anyone has suggestions or experiences that might help determine the best path forward, please share!

[Zac-Zajdel]

I would love to see this @ahinkle.

I agree with @taylorotwell that the amount of controller stubs is a bit intense 😅

I just started up a project I plan to host on Laravel Cloud and had some customizations I wanted to make to the stubs (I am looking at you declare(strict_types=1);). The sheer amount it gave me was definitely overwhelming and having to delete so many I didn't want to customize just to keep the ones I did felt a little unpolished which is a rare feeling in the Laravel ecosystem.

I believe making this change also keeps with the theme of having a more streamlined application structure that was introduced in Laravel 11 and makes the power of customization a lot simpler for the newbies :)

I love the idea about grouping by category. This along with Laravel Prompts would create such a nice user experience.

Looking forward to hopefully seeing this part of the framework!

[shaedrich]

I am looking at you declare(strict_types=1);

Good point. Maybe, it could reduce the number of stubs if the initial stubs for a project would be generated when needed from config, so they would be dynamic by nature, meaning, we wouldn't need some options at all, especially global ones.