tempestphp / tempest-framework

The PHP framework that gets out of your way 🌊
https://tempest.stitcher.io
MIT License
626 stars 43 forks source link

Move console commands #256

Closed aidan-casey closed 3 weeks ago

aidan-casey commented 3 months ago

Right now (for legacy reasons) console commands live in the Tempest\Console\Commands namespace that can be moved elsewhere (e.g., MigrateUpCommand).

We should move these to a Console directory under their respective components. At that point, we need to decide whether it makes most sense to actually require the console component in the composer file or move attributes to a global namespace or do something entirely different.

aidan-casey commented 3 months ago

@brendt - I'd welcome your feedback here.

brendt commented 3 months ago

it makes most sense to actually require the console component in the composer file or move attributes to a global namespace or do something entirely different.

I don't fully get this point, I'm afraid. But I get the problem with namespace collisions. I want to avoid having a Commands namespace, because that's confusing with the commandbus implementation.

I think we'd need something like this? Tempest\Framework\ConsoleCommands\… Would that be possible?

aidan-casey commented 3 months ago

@brendt - my recommendation was to move them to the namespace they are related to. For example, migration commands might be in Tempest\Database\Console.

The only problem I can see with this is that you could include those commands without requiring the console package as a dependency for that package, but we still have to have the attributes somehow. Do we move attributes to a common namespace similar to how Laravel has a Contracts namespace?

brendt commented 2 months ago

Well this is one of those things that had me worried about too many components :p

But, no problem, I think it's pretty clear to me — my vision, at least — component packages should be truly standalone (tempest/database shouldn't have a dependency on tempest/console). That also means though that this package cannot contain any console commands. It's the framework package that brings everything together, and thus adds commands for many components. I'd like to follow that structure for now. We can always move console commands to a package "down the line" without it being a breaking change, but we cannot move them "up" anymore. So let's keep console commands in "the framework" for now, and see how far we can get with that.

Does that sound reasonable?

aidan-casey commented 2 months ago

@brendt that sounds totally reasonable and probably better practice. Does it make sense to keep all these framework specific things confined to a namespace like Laravel does with the Foundation namespace?

brendt commented 2 months ago

Yes, I thought to call that namespace Framework

brendt commented 3 weeks ago

All framework specific commands are now in the Framework namespace