Refactor: Extract CLI input/output/command handling out of import.php

[atanas-dev]

Some of the abstractions may be a bit much but their usage is relatively decoupled and easy to refactor or eliminate in the future.

[github-actions]

Pull pipeline performance — large-directory

Site: large-directory · 2,000+ plus targeted file-transfer scenarios files · 10,000 posts · 25,000 postmeta · PHP 8.5.9

Stage	PR	trunk	Δ	Status	Details
playground-sqlite-db-pull	8.82 s	8.55 s	⚪ +265 ms (+3.1%)	✓	condition=db-pull in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=lexer native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=selected trunk: condition=db-pull in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=lexer native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=selected
playground-sqlite-db-apply	3.50 s	3.60 s	⚪ -102 ms (-2.8%)	✓	condition=db-apply to SQLite in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=parser native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=verified native_ast=WP_MySQL_Native_Parser_Node sqlite_driver_parser=verified trunk: condition=db-apply to SQLite in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=parser native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=verified native_ast=WP_MySQL_Native_Parser_Node sqlite_driver_parser=verified
Total	12.31 s	12.15 s	⚪ +163 ms (+1.3%)

_{Numbers carry runner noise; treat single-run deltas as directional, not authoritative.}

_{📈 Trunk performance history — commit-by-commit timeline.}

[adamziel]

We're adding a lot of custom abstraction here. Is there any small, dependency-free composer package out there that we could bring in and get a complete, battle-tested, documented CLI runner in like 5kb?

[WPprodigy]

I've never found a small one that I've liked TBH, they all tend to add in a lot of features and complexities. I tend to end up just rolling my own CLI abstraction using the command pattern like this PR does, since it's pretty straightforward and simple.

I prefer this approach for starting out for sure though. The abstraction is going to need some tweaking along the way, but this is a good step in the right direction IMO. Adding a composer package in the future to handle this command abstraction layer wouldn't be hard, removing one though is typically harder.

[atanas-dev]

I agree with @WPprodigy. I'm definitely not saying the current implementation is perfect, but it's good enough and, more importantly, it's decoupled and can be swapped out with a different solution at a moment's notice, as it all boils down to [code that parses CLI input] -> [call execute_invocation()].

[adamziel]

OK, this might be a good start indeed if we go the "one class per command" route. Something about this makes me uneasy. I'll explore a "move all the CLI logic into a single side class" in a draft PR to taste what an alternative approach feels like and then let's compare.

[adamziel]

That was fast! Codex came up with this: #561

I kinda like it as a middle ground between a complete monolith and a CLI sub-framework. What do you think?

[WPprodigy]

if we go the "one class per command" route. Something about this makes me uneasy.

I'm curious what you don't like about that direction. Personally, I find it much easier to navigate and understand a codebase built like that. The command pattern just feels like a perfect match for this to me.

Commands are often going to have specialized logic that only it needs, and adding/refactoring methods declared inside a command-specific class is a lot easier and safer than trying to change things in one megaclass where it's not clear what all is using what. A lot of the internal "meat" could still be shared in a similiar manner that it currently is, the commands just fit it into a clean re-usable pattern that gives easy mental overviews of the entry point/middle/exit point.