Future of TYPO3 command line

[bfr1 (Benjamin Franzke)]

General

The motivation for this change/decision is to fix the upgrade:run command which was introduced in 9.4. It is a lowlevel command and requires a failsafe boot, like the install tool does. The respective issue can be found at https://forge.typo3.org/issues/86248
Therefore we need some kind of decision prior the release of 9LTS.

Alternative 1) One tool for each use case – Additional Pros

• Clear guidance to the integrator, that there is a designated maintenance tool (typo3ctl), intended for deployment scripting
• Quick command lookup due to shorter command lists
• bin/typo3ctl may be used next to helhum/typo3-console. While helhum/typo3-console replaces bin/typo3 a separate bin/typo3ctl utility allows faster adaption of the core solution. The developer is still able to use helhum/typo3-console for features not yet available in core, but can use the new bin/typo3ctl tool for maintenance tasks – allows easier preparation for the future.

Alternative 1) One tool for each use case – Cons

@helhum

• Two different entry and goto points for users

This is actually a “Pro”, as the user has to read less commands in tool help in total. They can find the command for their usecase quicker.

@helhum

Maintenance commands are not always low level commands. upgrade:run needs a full bootstrap in the end and might still fail in a not set up state of TYPO3

In needs to bootstrap in the end, not in the beginning. Thats an important fact and actually a Pro. A late boot allows to properly catch errors in upgrade:run (like the install tool does as well)

@helhum

• Convenience commands like server:run to start a simple PHP webserver (does not exist for TYPO3 yet) are clearly not maintenance commands, but still need a stripped down bootstrap to work

I think this example is better suited to a task runner (use compoer scripts or makefiles). Not a Con, rather a Pro, when we instruct people to use proper task runners.

@helhum

• It is not clear where to put commands use cases that fit into both like language:update or referenceindex:update

If something really belongs to both categories, then it may be provided in both tools. Though I’m not saying we should do this. We should rather aim for implementing it in one tool. (means maintenance for you examples)

Alternative 2) One tool for all use cases – Pros

@helhum

• One goto point for users

I see this as a Con, the user doesn’t know what environment a command requires and in which situations it may be used.

@helhum

• Similar to the integration of the install tool in the backend, we have one unified “UI” to accomplish multiple tasks

From an end-user standpoint it’s quite similar, but it would only be similar if we would spawn a subprocess.
Also, despite the UI in the Backend, there is still a separate Install Tool available, which is the goto point when you do an upgrade/maintenance. That seperate tool is missing with the one-tool-solution.

Alternative 2) One tool for all use cases – Additional Cons

• No clear distinction, which commands might be used in which scenario (especially deployment)
• Requires uncached Bootstrap
• It prohibits further improvements to the Bootstrap code, as it limits to uncached execution. We will have hard times integrating a compiled container like symfony/dependency-injection which would be required to run uncached (that means compilation for every CLI run, that’ll be performance hell)

Further considerations

@helhum

In composer mode we write a compiled file with all (via composer installed) extensions to a know location and in the binary, we can just read that file and the information which commands of which type are available and run a fully cached or uncached bootstrap for each command.

That means the maintenace tool is composer. (which generates the command map)
Which (maintenance?) command repairs that command map in classic mode?

@helhum

• To achieve that is a solvable technical problem, even if keep one binary

Both solutions should be solvable, somehow, or we wouldn’t need to discuss here
But “solvable” doesn’t mean that the code is clean or maintainable.

To summarize (my thoughts):
bin/typo3 can be made quite solid in future (for composer installations), but will be a nightmare during development having to use bin/typo3 dump:commandmap for every new command
bin/typo3ctl solves this now and additionally provides clear separation of usecases.