Refactor sake around Symfony console

[emteknetnz]

sake is basic though functional way to run cli commands

It's very non-standard, and it's likely that we could make the interface significantly better by changing it to use symfony/console instead. There may also be some downstream benefits of making it easier to project to extend/customise if they have a need to

Related

• RFC: Use Symfony Console Component for Tasks and better cli support #5542
• dev/tasks on command line are very hard to read #8998
• RFC: Avoid HTTPApplication for CLI #7509

Acceptance criteria

• First determine if this is something that's viable without breaking much in terms of backward compatibility i.e. user should still call sake, though possibly some of the commands are different, though preferably not
• Target CMS 6
• Replace as much of sake with symfony/console as possible

CMS 5 PRs

• Various deprecations and a few features #11365
• API Deprecate API that will be removed silverstripe-graphql#603
• API Deprecate API that will be removed silverstripe-ldap#91
• API Deprecate API that will be removed silverstripe-subsites#599
• API Deprecate API that will be removed silverstripe-externallinks#147
• API Deprecate API that will be removed silverstripe-realme#162
• API Deprecate API that will be removed silverstripe-staticpublishqueue#203
• API Deprecate API that will be removed silverstripe-contentreview#257
• API Deprecate API that will be removed silverstripe-crontask#94
• API Deprecate API that will be removed silverstripe-graphql-devtools#60
• API Deprecate API that will be removed tractorcow-farm/silverstripe-fluent#887
• API Deprecate API that will be removed bringyourownideas/silverstripe-maintenance#240
• API Deprecate API that will be removed symbiote/silverstripe-queuedjobs#447
• DOCS Document deprecated API and a few new features developer-docs#580
• Merge branch '7' into 8 tractorcow-farm/silverstripe-fluent#890

CMS 6 PRs

kitchen sink run

• NEW Refactor CLI interaction with Silverstripe app #11353
• API Update API to reflect changes to CLI interaction silverstripe-testsession#93
• API Update API to reflect changes to CLI interaction silverstripe-graphql#600
• API Update API to reflect changes to CLI interaction silverstripe-session-manager#213
• API Update API to reflect changes to CLI interaction silverstripe-frameworktest#203
• API Update API to reflect changes to CLI interaction silverstripe-assets#635
• API Update API to reflect changes to CLI interaction silverstripe-ldap#89
• API Update API to reflect changes to CLI interaction silverstripe-linkfield#329
• API Update API to reflect changes to CLI interaction silverstripe-subsites#597
• API Update API to reflect changes to CLI interaction silverstripe-externallinks#145
• API Update API to reflect changes to CLI interaction silverstripe-realme#160
• API Update API to reflect changes to CLI interaction silverstripe-staticpublishqueue#201
• API Update API to reflect changes to CLI interaction silverstripe-userforms#1325
• API Update API to reflect changes to CLI interaction silverstripe-contentreview#255
• API Update API to reflect changes to CLI interaction silverstripe-sharedraftcontent#259
• API Update API to reflect changes to CLI interaction silverstripe-graphql-devtools#58
• API Update API to reflect changes to CLI interaction silverstripe-elemental#1252
• API Update API to reflect changes in CLI interaction silverstripe-crontask#93
• API Update API to reflect changes to CLI interaction symbiote/silverstripe-advancedworkflow#552
• API Update API to reflect changes to CLI interaction symbiote/silverstripe-queuedjobs#445
• API Update API to reflect changes to CLI interaction tractorcow-farm/silverstripe-fluent#884
• API Update API to reflect changes to CLI interaction bringyourownideas/silverstripe-maintenance#239
• API Update API to reflect changes to CLI interaction bringyourownideas/silverstripe-composer-update-checker#97
• ENH Update config to reflect changes in CLI interaction silverstripe-environmentcheck#112
• ENH Use standardised BackURL instead of non-standard returnURL silverstripe-cms#2999
• DOC Update docs to reflect new sake commands silverstripe-tagfield#307
• DOC Update docs to reflect changes in CLI interaction silverstripe-behat-extension#282
• DOC Update docs to reflect changes in CLI interaction silverstripe-taxonomy#123
• DOC Update docs to reflect changes in CLI interaction silverstripe-registry#107
• DOC Update docs to reflect changes in CLI interaction silverstripe-auditor#92
• DOC Update docs to reflect changes in CLI interaction silverstripe-siteconfig#176
• DOC Update docs to reflect changes in CLI interaction silverstripe-spamprotection#127
• DOC Update docs to reflect changes in CLI interaction silverstripe-hybridsessions#113
• DEP Update dep for graphql-devtools recipe-kitchen-sink#72
• DOC Document changes to CLI interaction developer-docs#571

[GuySartorelli]

I've gotten pretty far with this for everything included in installer. I'm nearly at the point where I can clean up and start writing tests (and then move onto the rest of kitchen sink).

One thing I'd like some opinions on is how the dev/ commands should be arranged.

Right now the PRs have these just swapping dev/ to dev:, i.e. you can run the commands like so:

HTTP route	CLI command	CLI alias (for backwards compat)
dev/tasks/my-task	dev:tasks:my-task	dev/tasks/my-task
dev/config	dev:config	dev/config
dev/build	dev:build	dev/build

This however keeps all of the commands clumped together in an unhelpful way, and means you have to type dev: before every command, which is completely unnecessary in the CLI. The only reason they had that historically is because sake was just a CLI wrapper for the HTTP controllers, so the routes had to be identical. Now they don't.

I would like to change the commands to be more meaningful in CLI, while keeping their HTTP routes as they currently are. That would look more like this:

HTTP route	CLI command	CLI alias (for backwards compat)
dev/tasks/my-task	tasks:my-task	dev/tasks/my-task
dev/config	config:dump	dev/config
dev/build	db:build	dev/build

This gives us a more sensible grouping for the CLI commands, allows for new commands to be more easily added to those groupings in a meaningful way, reduces unnecessary key-strokes, and I think just looks way tidier.

(I'm planning on hiding the tasks from this initial list (at least if there are more than some configurable number of them) and only showing them when you run sake tasks (or sake dev:tasks if this proposal isn't accepted) so don't get too caught up on how those are filling the output)

@silverstripe/core-team Does anyone have any thoughts on this?

[wilr]

@GuySartorelli 100% agree. Coming from a laravel view that makes a lot more sense than prefixing everything dev. 👍

[emteknetnz]

Looks good, happy to get rid of the dev prefix

[kinglozzer]

+1 for getting rid of the dev prefix

[michalkleiner]

All good to drop the dev: prefix.

[emteknetnz]

@GuySartorelli Will need to rebase the PRs that have phpunit/phpunit in require rather than require-dev. behat-extension is one of them, there may be others.

I'm unable to install of the PR's at the same time locally due to conflicts between phpunit 11 which was just merged and phpunit 9

[GuySartorelli]

Yup there's rebasing to be done, just needed that CMS 5 pr merged first 👍

[emteknetnz]

@GuySartorelli A few things I've noticed from doing some quick testing locally, which I'll not here rather than on individual PRs where they'll need to be fixed:

• Running sake tasks lists a bunch of tasks in a mixture of casing, e.g. tasks:WorkflowReminderTask and tasks:content-review-emails. We should only have a single style, which to me seems like it could be the WorkflowReminderTask style as that matches the class name which people are familiar with. The command names and docs will need to be updated.
• sake dev/tasks and dev/graphql and simply sake dev don't work like they used to, though dev/build and dev/config do work which is inconsistent
• There's some text which doesn't make sense in a CLI context, e.g. sake tasks:delete-queued-jobs will prompt Really delete 3 jobs? Please add ?confirm=1 to the URL to confirm. - should be prompting use to add --confirm when in CLI instead