Technical Evaluation

Architecture fit

This is a build-time static analysis tool, not a runtime library. It parses PHP source with nikic/php-parser and emits a JSON document describing do_action* / apply_filters* call sites and their docblocks — no WordPress bootstrap required. That makes it a clean fit for CI containers and headless setups (e.g., a Laravel app that owns a WordPress content backend, or a monorepo of WP plugins).
It does not integrate with Laravel's container, config, or Artisan layer — it is a Composer dev dependency with a CLI entry point. Treat it as tooling in the same category as PHPStan or Pint, not as an application dependency.
Natural consumers of its output: documentation sites, IDE/Intelephense stubs, contract tests for plugin extension points, and hook-usage registries.

Integration feasibility

Low-friction to trial: composer require --dev, run against one package, inspect JSON. No schema migrations, no database, no service to operate.
Wrapping it is straightforward — a thin Artisan command or Composer script that shells out to the binary and post-processes the JSON gives us a first-class DX without forking the package.
Confirm the binary name and exit-code behaviour from composer.json before automating; do not assume CLI contract stability across versions.

Technical risk

Silent under-extraction is the dominant risk. Dynamic hook names (do_action($name), interpolation, hooks returned from arrays/factories) are invisible to static analysis. The output will look complete while being partial — the most dangerous failure mode for a documentation or contract-testing use case.
Adoption signal is weak. 87 stars, 0 tracked dependents, low overall score. That is not disqualifying for a dev tool but implies thin edge-case coverage, a bus factor of roughly one, and a real chance of abandonment. Plan a fork/vendor contingency.
Dependency surface: nikic/php-parser is shared with PHPStan, Rector, and Pint. Version-pin conflicts in a mature dev-dependency graph are likely and must be checked per-repo.
Opaque scoring: composite score 13.3 with opportunity 30.5 — reads as "useful niche tool, unproven ecosystem." Weight accordingly.

Key questions

What percentage of our hooks use dynamic names? If high, expected value drops sharply.
Does it parse our full PHP version matrix (8.1–8.4 constructs, enums, attributes, readonly)?
Where does the JSON live — committed artifact, CI artifact, or docs-site input? Who owns schema stability?
License and maintainer responsiveness; is there an active release cadence (last release 2026-05-22 suggests yes, but verify commit recency and issue triage)?
Do we need the JSON as an external contract (published, versioned) or only as an internal lint aid? The governance burden differs by an order of magnitude.

Integration Approach

Stack fit

Composer-native, PSR-4, framework-agnostic. Drops into any PHP repo without touching runtime autoloading.
In a Laravel-primary organisation it belongs in the require-dev block of the WordPress-adjacent packages, invoked from a Composer script or an Artisan command; in a polyrepo it belongs in a dedicated tooling/ package pinned once and consumed everywhere.
Complementary, not overlapping, with Laravel's own tooling: artisan route:list-style introspection covers Laravel hooks; this covers the WordPress extension surface that Laravel has no visibility into.

Migration path

Phase 0 (spike, ~1 day): run against a single representative plugin, diff generated JSON against the team's mental model of its hooks. This immediately quantifies the dynamic-hook blind spot.
Phase 1: commit the JSON as a reviewable artifact and add a CI step that regenerates and fails on unexpected diff. Zero runtime change, fully reversible.
Phase 2: feed JSON into docs generation and IDE stubs; expand to all WordPress-facing packages.
No user-facing migration, no data migration, no cutover event — the entire adoption is additive.

Compatibility

Verify the package's PHP constraint against our runtime/CI matrix before anything else; a mismatch here is the single most likely blocker.
Run composer why nikic/php-parser and a dry-run composer update --with-dependencies on a branch to surface constraint conflicts with PHPStan/Rector/Pint before committing to adoption.
JSON schema versioning: downstream consumers (docs site, IDE stubs) must tolerate additive fields; pin the generator version in lockstep with the consumer.

Sequencing

Compatibility + dependency-conflict spike (highest-risk, cheapest to test).
Extraction-fidelity spike on the messiest real codebase — measure recall against a manually enumerated hook list.
Define the JSON storage/ownership contract and CI gate.
Wire docs and IDE-stub consumers.
Roll out package-by-package; add to the repo template only after two clean adoptions.

Maintenance

Dev-only dependency: zero production blast radius. Worst case is a red CI job.
Pin exact versions; read the changelog on every bump because output schema changes silently break downstream docs and stubs.
Budget ~2–4 hours per quarter for version bumps and dependency-conflict resolution — modest but non-zero, and it will compete with other tooling upgrades sharing php-parser.

Support

No end-user support surface. Internal consumers are the docs pipeline and IDE tooling; the "support" burden is answering "why is hook X missing from the docs?" — which is really the dynamic-hook question in disguise.
Ramp-up for an engineer is roughly half a day: install, run, read JSON. No framework knowledge required beyond PHP and WordPress hook conventions.

Scaling

Cost is linear in source size and comfortably within CI budgets for repos up to tens of thousands of files; parallelise per package rather than optimising the tool.
Output artifacts grow with codebase size — set retention/commit policy early, since a large committed JSON diff makes code review noisy and invites --no-verify culture.

Failure modes

Mode	Impact	Mitigation
Dynamic hooks silently omitted	Docs/contracts incomplete, false confidence	Publish a known-limitations note; add a manual checklist for dynamic cases
`php-parser` constraint conflict	`composer install` breaks across the dev toolchain	Pre-flight check; isolate the tool in its own Composer context
Output schema drift on upgrade	Docs/stub generators break	Pin version; snapshot-test the JSON schema in CI
Package abandonment	Tooling rots as PHP evolves	Fork contingency; keep the invocation thin so swapping is cheap
Noise in generated JSON diffs	Review fatigue, suppressed diffs	Commit only on release branches, or publish as a CI artifact

Ramp-up / verdict

Time to first value: about one engineer-day. Time to organisation-wide value: 2–3 weeks including the docs and IDE-stub consumers.
Recommend adopt as internal tooling with a pin-and-fork contingency, scoped to WordPress extension surface we actually own. Do not present its output as a complete API contract, and do not adopt it as a hard gate (fail-the-build on diff) until extraction fidelity has been measured on our worst-behaved codebase.