[8.x] Allow dependencies to be injected into migrations constructor

[antonkomarev]

In some cases you might need access to the container to ensure the proper update of your data structure. This could be necessary to update relations with some specific logic or to create new entities.

class CreateDemoTable extends Migration
{
    public function __construct(TenantManagerInterface $tenantManager)
    {
        $this->tenantManager = $tenantManager;
    }

    public function up(): void
    {
    }
}

This question was raised many times before:

• [6.x] Resolve migration classes via the container #30590 L6.x
• [5.7] Services can be injected in migrations #25038 L5.7
• [5.5] Autowire migrations #21999 L5.5
• [5.3] Inject migration dependencies from container #13069 L5.3
• [5.0] Automatically Resolve Migrations Dependencies #6784 L5.0
• DI via constructor for Migration classes #4259 L4.1

[antonkomarev]

If you are rejecting this approach - I could propose another one.
It's not so neat, but we could introduce special contract which will be used to set container via mutator method.

use Illuminate\Contracts\Container\Container;

class CreateDemoTable extends Migration implements ContainerAwareInterface
{
    private $container;

    public function setContainer(Container $container)
    {
        $this->container = $container;
    }

    public function up(): void
    {
    }
}

Personally I don't like it, but leaving it for consideration of all possible alternatives.

[antonkomarev]

Container is nullable by default as @GrahamCampbell proposed. @taylorotwell if you still don't want to force all migrations to use DI - I could revert changes in service provider and keep them for Migrator class only. Then to enable DI in migrations people will only need to overwrite Migrator binding without extending and overriding class itself.

[taylorotwell]

$this->tenantManager = app(TenantManagerInterface::class);