leovie/php-method-runner
A lightweight PHP utility that lets you run methods on objects by name, making it easy to invoke dynamic or configurable method calls without verbose reflection code. Ideal for small Laravel or standalone PHP projects.
Architecture fit. Unchanged. leovie/php-method-runner remains a narrow tooling primitive — reconstruct a method from source, invoke it — and belongs in an analysis pipeline, code-generation validation harness, or "does this generated snippet actually run?" gate. It still does not belong in a request lifecycle or anything customer-facing. v3.0.1 does not add contracts, configuration, or framework integration, so the coupling profile is the same: low surface, but all safety and ergonomics remain yours.
Integration feasibility. Still mechanically trivial (Composer, BSD-3-Clause, no service provider). One signal in this release is worth acting on: the package is not frozen at 2022. The changelog references a v3.0.0 → v3.0.1 transition, which means a v3 line exists that the prior assessment did not account for. Before pinning anything, re-baseline: confirm the current PHP constraint, the nikic/php-parser major version, and whether the v3.0.0 bump carried a PHP floor raise or a parser major bump. A major-version step is exactly where a PHP ceiling or a PHPStan/Rector/Pint conflict would have been introduced. Feasibility as a one-to-two day spike is unchanged; feasibility as a supported dependency for a revenue path is still no.
Technical risk. The three original risks stand, with one refinement and one new detail:
echo/print to stdout — consistent with eval or a temp-file include. That confirms the package cannot give you a real timeout or crash isolation on its own. This is the single most important thing v3.0.1 tells you.$this, use imports, self::/static::, class constants, traits, and closure scope. Silent-and-wrong remains the failure mode to design against, not the loud one.New behavioural risk introduced by v3.0.1. Output suppression changes the observable contract. If any existing harness inferred success from the runner emitting the method's output, or scraped that output, it will now see an empty string and may read as a false failure. Conversely, if you had been consuming stdout in a JSON-emitting artisan command, this release removes the pollution you were previously working around. Either way, it is a semantic change to verify, not a cosmetic one — and it makes silent-incorrect execution harder to notice, because the discarded output was often the only evidence of what actually ran.
Key questions. Prior questions still open — eval vs include vs subprocess, out-of-process capability, use/dependency resolution, PHP constraint for 8.2/8.3, test suite, $this binding, E_ERROR handling — plus: does "suppress output" mean ob_start/discard, or a flag? Is it opt-in or default? Is the method's return value still surfaced, or is it output-only? And what changed in v3.0.0 relative to the 2022 release?
Stack fit. Unchanged: require-dev only, consumed by one artisan command or internal queued job, no service provider, one factory in your own namespace.
Migration path. The exit-ramp strategy is now more clearly the right one. Define MethodRunner::run(string $source, array $args): RunResult, where RunResult explicitly carries return value, captured output, and thrown error — never rely on the method echoing. Implement behind it with the package first. The v3.0.1 change is a good argument for owning that contract: output buffering semantics are precisely the kind of detail you want inside your wrapper, not leaking into call sites. Alternatives remain: php-parser + Symfony Process against a generated throwaway script (real timeouts, crash isolation), extractor-only for the parse half, or fork into app/Support/.
Compatibility. Re-verify against your Laravel target after the v3 rebaseline — check the PHP floor and the php-parser major against your static-analysis toolchain, which is still the likeliest source of a wasted afternoon. Pin to a commit hash of the v3.0.1 tag rather than a floating constraint.
Sequencing. (1) Diff v3.0.0 and v3.0.1, and read the source — still small enough to audit in an afternoon. (2) Confirm output-suppression behaviour with a two-line spike (method that echoes, method that returns). (3) Re-run the sandboxed PoC: Docker, no network, no writable FS, hard wall-clock limit at container level. (4) Wrap behind your contract. (5) Decide adopt-vs-fork on how much you patched. (6) If adopted, vendor the patched copy.
Maintenance. Still effectively self-maintained, but with mildly better odds of upstream response than previously assessed. Keep the named owner, the vendored copy under version control, and your own tests over the methods you actually execute. Do not read one PR as a durability guarantee.
Support. No SLA, no documented issue corpus. Unchanged.
Scaling. Unchanged and now better-evidenced: in-process execution means one method at a time per worker and no timeout. Queue with worker recycling (--max-jobs) to bound memory and contain fatals; batch aggressively to amortise spawn/parse cost.
Failure modes to design for. Uncaught E_ERROR/parse error killing the worker; infinite loops with no in-process recovery; autoload/namespace collisions across successively evaluated methods; global/static state bleeding in long-lived workers; and the quiet one — successful-but-incorrect execution from lost scope. Add one from this release: lost diagnostic signal. With output suppressed, a wrong result now looks identical to a correct one at the stdout layer. Compensate by asserting on captured return values and logging the reconstructed source alongside every run, at least until you trust the wrapper.
Ramp-up. Unchanged at roughly two to five days for a senior PHP engineer to be productive and to have built the isolation harness — plus an hour or two to re-baseline the v3 line. If untrusted input is ever in scope, add a security review.
How can I help you explore Laravel packages today?