Feature request: support DI container resolution for task instantiation

[jamisonbryant]

Problem

Tasks cannot use constructor-based dependency injection. The only DI mechanism is ServicesTrait::getService() inside run(), since setContainer() is called after construction. This prevents readonly promoted properties and doesn't match the pattern CakePHP uses for Components and Commands.

How Components do it

CakePHP Components accept DI dependencies alongside the framework-required ComponentRegistry in their constructor:

public function __construct(
    ComponentRegistry $registry,
    private UserService $users,
    array $config = [],
) {
    parent::__construct($registry, $config);
}

The DI container resolves all arguments. The component just passes the framework args to the parent.

Why tasks can't do this today

Processor::loadTask() hard-codes new $className($this->io, $this->logger). If a task declares additional constructor parameters, instantiation fails because the Processor only passes two arguments.

The Processor already has access to the DI container ($this->container) but doesn't use it for task resolution.

Proposed change

In Processor::loadTask(), try the container first for explicitly registered tasks, fall through to direct instantiation for everything else:

protected function loadTask(string $taskName): TaskInterface {
    $className = $this->getTaskClass($taskName);

    if ($this->container && $this->container->has($className)) {
        $task = $this->container->get($className);
    } else {
        $task = new $className($this->io, $this->logger);
    }

    if (!$task instanceof TaskInterface) {
        throw new RuntimeException('Task must implement ' . TaskInterface::class);
    }

    return $task;
}

Remaining issue: Io and LoggerInterface

The Processor creates runtime-specific Io and LoggerInterface instances (based on CLI flags like --quiet, --logger). These aren't in the app's DI container.

For container-resolved tasks, the base Task::__construct() defaults Io to new Io(new ConsoleIo()) when null. This means container-resolved tasks would get a different Io than the Processor's, causing output capture and logging to misbehave.

A few ways to solve this:

A) Add setIo() / setLogger() to the base Task, called by the Processor after loadTask() regardless of instantiation path. Simple, explicit.

B) Have the Processor register its Io and LoggerInterface in the container before resolving tasks.

C) Accept that container-resolved tasks include Io and LoggerInterface in their constructor (like Components include ComponentRegistry), registered as arguments in the service provider. The Processor would need to ensure these are available in the container.

Backward compatibility

Fully backward-compatible. Tasks not registered in the container are instantiated exactly as today. The ServicesTrait / setContainer() pattern continues to work.

Desired end state

// Service provider registration
$container->add(EndEventTask::class)
    ->addArgument(Io::class)
    ->addArgument(LoggerInterface::class)
    ->addArgument(MyService::class);

// Task class
class EndEventTask extends Task
{
    public function __construct(
        ?Io $io = null,
        ?LoggerInterface $logger = null,
        protected readonly MyService $myService,
    ) {
        parent::__construct($io, $logger);
    }

    public function run(array $data, int $jobId): void
    {
        $this->myService->doWork($data);
    }
}

Happy to contribute a PR if there's a preferred direction for the Io/LoggerInterface resolution.

[dereuromark]

Option A is the way to go.
Something like

  protected function loadTask(string $taskName): TaskInterface {                                                                                                              
      $className = $this->getTaskClass($taskName);                                                                                                                            
                                                                                                                                                                              
      if ($this->container && $this->container->has($className)) {                                                                                                            
          $task = $this->container->get($className);                                                                                                                          
      } else {                                                                                                                                                                
          $task = new $className($this->io, $this->logger);                                                                                                                                           
      }                                                                                                                                                                                                                                                                                     
                                                                                                                                                                              
      return $task;                                                                                                                                                           
  }     

maybe?

NOTE: untested

[jamisonbryant]

Feature: jamisonbryant#1

Docs: jamisonbryant#2

[dereuromark]

The PR needs to target upstream.

[dereuromark]

Oh, I totally forgot, didnt Kevin already add DI a while back.
I am not using it yet on those but you should check it out.

[jamisonbryant]

Since DI is already supported, and I am looking at other plugins as well, I will close this issue as the feature I was requesting was specific to my workflow/app. Thank you to everyone who took a look along the way.