Derive the plugin directory name in the wp-env scripts

[sirreal]

The wp-env npm scripts (composer, composer:setup, test:phpunit) hardcode wp-content/plugins/phpdoc-parser as the container path. wp-env mounts the checkout under its directory basename, so the scripts break for any checkout not named exactly phpdoc-parser — git worktrees, renamed clones.

Derive the path with $(basename "$PWD") so the scripts work for any checkout name. Verified by running the suite through npm run test:phpunit from a worktree named phpdoc-parser-pr262-fixes.

Extracted from #262 to keep that PR focused on export semantics.

🤖 Generated with Claude Code

[sirreal]

Note

This is an agentic review, generated by Claude Code at the repository owner's request.

Ready to land after #283. No defects; the only thing holding it is merge ordering.

Verified

• CI green on 7.4 and 8.4; mergeable, clean, based on master.
• The premise is exactly right. @wordpress/env's parse-source-string.js derives a local source's mount name with path.basename( sourcePath ) (line 58) and mounts it at wp-content/plugins/<basename>. Both .wp-env.json and .wp-env.test.json list "." as the plugin source, so the container path is the basename of the checkout directory — hardcoding phpdoc-parser really does break worktrees and renamed clones.
• $PWD is safe here, which was my main worry. npm runs scripts with cwd set to the package root, and a script invoked from a subdirectory still sees the package root in $PWD: I ran npm run from a subdir and got PWD=<package root>, base=<package root basename>. A stale inherited PWD is also reset by sh at startup (verified with env PWD=/some/where/else sh -c 'echo $PWD'). No need for $(pwd).
• The nested quoting is valid POSIX. The shell sees --env-cwd="wp-content/plugins/$(basename "$PWD")"; inside $( ) the quoting context restarts, so the inner "$PWD" is a properly quoted word, and directory names containing spaces survive. Verified by execution, not just by reading.
• In GitHub Actions the workspace basename is phpdoc-parser, so npm run test:phpunit:setup / npm run test are unchanged there — consistent with CI passing.

Worth noting

• Not a regression, but for the record: these scripts are already broken under cmd.exe on Windows (npm's default script shell there), where the pre-existing single quotes are not quotes either. $(basename "$PWD") does not make that worse. If Windows support ever matters, "script-shell" in .npmrc is the fix, not this line.

Ordering

#283 changes the composer passthrough line in the same file (dropping --no-security-blocking, which is an install-only option). Land #283 first, then rebase this one by removing that flag from the rewritten passthrough line:

"composer": "wp-env --config .wp-env.test.json run --env-cwd=\"wp-content/plugins/$(basename \"$PWD\")\" wordpress composer --no-interaction"

composer:setup keeps --no-security-blocking as it does today. Expect a one-line conflict, nothing more.