Php Method Runner Laravel Package

Product Decisions This Supports

• Configurable business logic / low-code rule engine. If admins author pricing, discount, eligibility, or scoring rules as PHP snippets stored in the DB, this package gives you a lightweight way to execute a method body in a fresh scope without hand-rolling ReflectionMethod + eval plumbing. It directly supports a build-vs-buy decision: "ship a rules engine this sprint" vs. "buy a workflow vendor."
• Plugin / extension architecture. Supports letting internal teams or vetted integrators contribute logic as a Method object executed on demand — useful as a per-tenant customization layer without a microservice per tenant.
• Code playground & documentation "try it" features. Run a documented method body against sample inputs to produce live examples. As of v3.0.1, method output is suppressed by default, so examples can be embedded in request/response paths without stray echo/print corrupting JSON bodies or headers.
• Migration and refactoring harnesses. Execute legacy method bodies inside a new test scaffold during a monolith-to-service move — useful for characterization tests and behavioral diffing.
• Code-generation verification. Assert that generated PHP (templates, scaffolding, DSL output) actually runs and returns the expected value. Output suppression makes assertion failures on stdout-less results less noisy.
• Transform pipeline / ETL. Store per-record transformation logic as code and apply it in-process.
• A/B or shadow testing of logic. Run both old and new method bodies on the same inputs and compare outputs before flipping a flag.

Roadmap caveat: this is an enabler, not a product differentiator. It shortens the time-to-first-version of the features above by days, not months; do not let a dependency this thin shape the roadmap itself.

When to Consider This Package

Consider adopting when:

• Your need is specifically "execute the body of an already-reflected PHP method" — you have a Method/source string from your own codebase or a trusted store, not arbitrary user input.
• You are on a PHP/Laravel stack and want a zero-config Composer dependency rather than writing your own scope-isolated executor.
• Inputs are trusted or semi-trusted (internal authors, reviewed admin snippets, generated code you control).
• You value a small, readable, forkable footprint over vendor support. BSD-3-Clause means you can vendor and modify it.
• You want an executor whose captured output does not leak into the response — v3.0.1 suppresses method output, which removes a common source of accidental noise in API responses and rendered pages.
• You are prototyping and want to validate the product concept before investing in a real sandbox.
• You need it for internal tooling (CI harnesses, migration scripts, doc examples) where a runtime failure or a stray side effect is annoying, not catastrophic.

Look elsewhere when:

• You need real isolation. This is not a security boundary. v3.0.1 suppresses output, not side effects — file writes, network calls, DB mutations, and mutations of injected objects all still happen. Untrusted or customer-supplied code requires process/container isolation (symfony/process, Docker, gVisor/Firecracker, Wasm) or a purpose-built sandbox. Running user code with access to your app's classes, env, and filesystem is a breach waiting to happen.
• You depend on the method's echoed output as part of its result. v3.0.1 changed the contract: output is swallowed. If a consumer relied on echo/print surfacing, wrap those methods, use an output buffer around the call, or return values instead. Treat this as a behavior change to verify on upgrade, not a cosmetic patch.
• The code isn't a method body. Arbitrary strings, expressions, or non-PHP DSLs are a better fit for nikic/php-parser + a custom interpreter, or a hosted execution service.
• You need maintenance guarantees. The project has resumed shipping a v3.0.x line, but a single output-suppression patch is a pulse, not a maintenance commitment; ecosystem adoption remains effectively nil (no meaningful dependents). If it's on a critical path, plan to fork and own it, and verify PHP-version compatibility and test coverage before committing.
• Performance matters at scale. If you'll execute this per-request or per-row at volume, measure spawn/eval overhead and consider compile-once/cache-result strategies instead.
• You need typed parameter binding, return-type enforcement, timeouts, or resource limits. You'll be building those yourself on top.

How to Pitch It (Stakeholders)

Executive summary. leovie/php-method-runner is a small, free, permissively licensed (BSD-3) PHP utility that lets our application execute the source of a PHP method at runtime. It is an accelerator, not a platform: it can shorten delivery of configurable business rules, tenant customizations, and internal code tooling by removing boilerplate. The latest patch (v3.0.1) suppresses method output, which makes it safer to drop into request paths, but it remains not a security sandbox (output is muted, side effects are not) and the project is thinly maintained (a small patch series, negligible ecosystem adoption). Recommendation: use it for internal, trusted-input scenarios and vendor/fork it so we own the code; if we ever expose code execution to customers, budget separately for real isolation. The cost of adoption is near zero; the cost of misuse is a security incident, so scope it deliberately.

For engineering. It eliminates the ReflectionMethod + scoped-eval plumbing needed to run a method body with controlled $this/arguments. Good fit for: rule engines over vetted snippets, code playgrounds, characterization tests during refactors, and generation-verification in CI. Upgrade note for v3.0.1: method output is now suppressed — audit any caller that consumed printed output and adapt it (output buffering around the call, or return values) before bumping the pin. Constraints still ours to solve: no process isolation, no timeouts or resource limits, no typed argument or return validation, and no protection against side effects (I/O, state mutation). Dependency risk remains real (one maintainer, negligible dependents); pin the version, add a smoke test matrix across our supported PHP versions, and be ready to maintain a fork. Prefer it where a failure is a bug, not a breach — and never where the input is untrusted.