Move console commands
aidan-casey opened this issue · comments
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.
@brendt - I'd welcome your feedback here.
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?
@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?
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?
@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?
Yes, I thought to call that namespace Framework
All framework specific commands are now in the Framework namespace