[Feature Request]: TODO list for make commands

[gturpin-dev]

Description

Hey @brendt This is my TODO list for future make commands that I'll work on soon Tell me if you prefer to skip issue and make it and discord or elsewhere. Could you assign me to this ?

Maybe you can tell me if you want some stuff in priority or if some commands seems useless for you. I'll update this list while reading the whole docs

• [ ] make:initializer
• [x] make:response
• [x] make:route ( for custom routes, not sure if it's helpful )
• [ ] make:view ( maybe one command with flags to make class or class component or raw view file )
• [ ] make:middleware ( with some flags like --http for middleware type )
• [ ] make:config ( not sure if it's helpful, but it could create a file named xxx.config.php with the suggested name as usual and maybe return a basic config object ? ) || Or another idea could be to have a select component where user can choose the config type to create ( e.g. DatabaseConfig or EventBusConfig other config types )
• [ ] make:migration => could create a migration class or with a flag like --raw a sql migration
• [ ] make:command => a generator command that make another command, the circle is now complete 😄
• [ ] make:generator-command => maybe a basic stub that follow other basic make commands using PublishesFiles and prompts
• [ ] make:event or make:event-handler => a class with a method with the #[EventHandler] attribute

Benefits

Keep an eye on progress of make commands 😄

[brendt]

make:route make:route ( for custom routes, not sure if it's helpful )

I don't think this is necessary atm

make:view ( maybe one command with flags to make class or class component or raw view file )

Do you intend this command to also make regular view files, or only components? I think this will be especially useful to make view components

make:middleware ( with some flags like --http for middleware type )

Hmm, a flag could work. If no flags were provided, you'd get a dropdown list. But maybe you should use an enum instead of a flag?

make:middleware [type]

make:config ( not sure if it's helpful, but it could create a file named xxx.config.php with the suggested name as usual and maybe return a basic config object ? ) || Or another idea could be to have a select component where user can choose the config type to create ( e.g. DatabaseConfig or EventBusConfig other config types )

Both are cool, I think the most useful implementation would be make:config without arguments, getting a prompt with all available configs, selecting one, and then create a default file in the right place.

make:generator-command => maybe a basic stub that follow other basic make commands using PublishesFiles and prompts

Maybe just a flag in make:command?

make:event or make:event-handler => a class with a method with the #[EventHandler] attribute

Hmm, not sure if this is really useful. By the time you've ran the command, you could have also made the class manually.

[brendt]

I shared some thoughts, but overall great list, I'm really excited about this! It's ok to keep it as one issue, I'd prefer separate PRs though :)

[gturpin-dev]

I don't think this is necessary atm

You're right, updated 😄

Do you intend this command to also make regular view files, or only components? I think this will be especially useful to make view components

Yes that was my thought when I wrote raw view file, maybe we can keep consistency with other commands, so having an Enum or a dropdown list ?

Hmm, a flag could work. If no flags were provided, you'd get a dropdown list. But maybe you should use an enum instead of a flag? make:middleware [type]

This makes sense to me, I'd go for an enum match for the first parameter "type" and then if nothing given, we give a dropdown list. Is this already provided by the "missing input component" when we have an enum parameter ? Otherwise It could be a great addition 👀

Both are cool, I think the most useful implementation would be make:config without arguments, getting a prompt with all available configs, selecting one, and then create a default file in the right place.

I think it's the better choice. I'll check later but I think all config are discovered by interface or something like that, so even the select prompt could be automated 😄

Maybe just a flag in make:command?

Yeah, probably better 👌

Hmm, not sure if this is really useful. By the time you've ran the command, you could have also made the class manually.

True, same goes for command bus and other things with no boilerplate in it.