Pass --no-security-blocking only to composer install

[sirreal]

--no-security-blocking is an install/update option, but the generic composer passthrough script passes it to every command, so anything else fails — e.g. npm run composer -- validate. The flag stays on composer:setup (install), and the passthrough keeps only --no-interaction.

Verified in the PHP 7.4 wordpress container: composer --no-interaction --no-security-blocking validate exits 1; without the flag it reports ./composer.json is valid. composer install --no-interaction --no-security-blocking continues to work (unchanged composer:setup path).

Overlaps trivially with #276, which rewrites the same lines to derive the plugin directory; whichever lands second rebases in seconds.

🤖 Generated with Claude Code

[sirreal]

Note

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

Ready to land. Land this before #276 — they collide on the same composer line.

Verified

• CI green on 7.4 and 8.4; mergeable, clean, based on master.

• The premise reproduces independently. On Composer 2.10.2, --no-security-blocking is listed only under composer help install (and the other install-family commands), not as a global option — composer help validate does not mention it, and running composer --no-interaction --no-security-blocking validate fails with:

  The "--no-security-blocking" option does not exist.

  Dropping the flag makes the same command report ./composer.json is valid. Exactly the behavior described in the PR body.

• The flag is retained where it is actually needed: composer:setup (the only install path in package.json) is untouched, and .github/workflows/unit-test.yml invokes composer install --no-interaction --no-security-blocking directly, so CI is unaffected. One line changed, nothing else.

Worth noting

• --no-security-blocking is deprecated as of Composer 2.10, in favour of --no-blocking: "DEPRECATED: use --no-blocking instead." Out of scope here — this PR is a strict improvement either way — but a small follow-up should sweep both remaining uses (package.json's composer:setup and unit-test.yml) before the option is removed.
• Minor consequence, presumably intended: npm run composer -- install and npm run composer -- update now go without the flag. The blessed path (composer:setup) still has it, so this only affects ad-hoc passthrough use.

Ordering

#276 rewrites all three of these script lines to derive the plugin directory, so the two PRs conflict on the composer entry. Landing this first is the cheaper order; #276 then just drops --no-security-blocking from its rewritten passthrough line, leaving:

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