It may be more involved than that. Here's a few examples that would be really useful to cover with a unit test to make sure this command can handle them without failing:

rm file1 file2 file3
rm -r -f directory
rm file1 -f file2 -r
# This one means "remove a file called "-rf"
rm -- -rf
# This one means "recursively remove a file or a directory called "-rf"
rm -rf -- -rf

@adamziel @zaerl What do you think about using the yargs-parser npm package to parse the args instead of writing a custom parser from scratch?

@Utsav-Ladani potentially! Let's give it a try and see what would this code look like with yargs-parser in place. It seems to be larger than we need, but still fairly small so perhaps? Note this package (@php-wasm/universal) can be imported in both node.js and web browser code, which yargs-parser seems to support. Also, one potentially relevant difference is that yargs-parser seems to accept a string, and in here we already have access to a pre-parsed args array where string syntax were already processed (e.g. "my string" becomes my string) – hopefully there's a way to work from there without re-encoding that and re-escaping quotes.

@adamziel I have updated the PR to try yargs-parser and it works for all cases you mentioned above, but we have an issue with the import.

import yargsParser from 'yargs-parser/browser'; is throwing process is not defined error as we are running it in the browser and import yargsParser from 'yargs-parser/browser'; is throwing type error.

Any exception thrown by php.isDir, php.isFile, php.rmdir, or php.unlink will bubble to the outer catch, which is documented as meaning 'the PHP runtime has crashed'. That will incorrectly treat routine filesystem errors (permission issues, transient FS errors, unexpected path formats) as a runtime crash. Handle expected per-target FS failures inside the rm case (e.g., wrap operations per target in try/catch, emit an rm:-style message to stderr, and set a non-zero exit code) so the handler reports command errors instead of misclassifying them as runtime crashes.

Avoid as any here—it's easy to accidentally access missing properties (e.g., parsedArgs._) without type checking and makes future refactors riskier. Prefer a small local type/interface for the subset you rely on (e.g., { _: string[]; recursive?: boolean; force?: boolean }), or use a typed return shape so targets, isRecursive, and isForce are derived from well-defined fields.