This change, alongside with the documentation update, should adhere to nette coding practice of defining all dependencies on constructor level.

I disagree about this one. I don't wanna prevent it, but I also don't wanna ecourage it.

Even though symfony recommends to use arbitraty configure method, using constructor is cleaner design IMHO.

I would like the avoid this discussion entirely and let everybody do it as they like. The configure method is a standard for the sf console and I don't wanna go against the documentation here. The command configure section can get quite long and having it in separate method (which is in fact called from the parent constructor) is a good thing IMHO.

Also, having them autowired should not cause any applications to break. Is there anything else that can be considered a BC Break?

So I see multiple stuff being discussed here, let's consolidate.

0. Docs. Your call - will update.
1. Constructor injection - What is your preferred approach? Let me know, I'll update.
2. __construct vs configure -- agreed, I'll update the docs

3. BC break
   the PR fix actually breaks using @inject and injectSomething() methods. Since the autowire happens by default on constructor, unless you define inject: true in your config.neon, the inject annotations & methods are not called.

As far as I understand it, this happens because I used Nette\DI\Compiler::parseService($def, $command); For some reason, it does not call the injectors or does not inject the properties.

Can be seen here:

• test config.neon - note the inject:true classes
• *NeedsAll classes do NOT have injects called/set
• *NeedsAllWithInject classes DO have injects called/set

BC break add - OH, I see, injects are called in doRunCommand.

But that means, if I inject a command into another command using DI, I won't have injects called properly. Maybe it would be cleaner to just remove the doRunCommand override from Application.php completely? That way DIC would take care of injects, as it should, imho.

Since the autowire happens by default on constructor

The construtor injection always worked, you just haven't had the full blown capabilities of configuring the service as in the services section.

As far as I understand it, this happens because I used Nette\DI\Compiler::parseService($def, $command); For some reason, it does not call the injectors or does not inject the properties.

to resolve the inject methods/properties is the job of InjectExtension, which must be enabled by the tag.

But that means, if I inject a command into another command using DI, I won't have injects called properly.

Yes, that's right, the "propper" way to invoke the command (if you must) is calling it through application. As there might be more to it's initialization (events, helpers, ...).

Or you know... you extract the logic so you don't have to hack it :)

Sorry, but I don't wanna introduce any more ways of doing the same thing. If you wanna better configuration of command services, just configure them as services and properly tag them.