Php Scoper Prefix Remover Laravel Package

Product Decisions This Supports

• Whether to scope dependencies at all. This package only has value downstream of a decision we've already made: ship self-contained PHP artifacts — WordPress plugins/themes with vendored libraries, distributed PHAR CLIs, white-label Laravel packages — through PHP-Scoper so they cannot collide with a host application's dependencies. If we ship Composer-resolved dependencies instead, the package is inert. The PM framing is not "should we adopt this library" but "do we accept the scoping pipeline and its toolchain liabilities?" Prefix removal is a downstream cleanup cost of that answer.
• Support and triage cost modelling. Scoped class names leaking into logs, crash reports, and customer-submitted stack traces (Scoped\Acme\Billing\Invoice instead of Acme\Billing\Invoice) directly raise time-to-diagnosis for support engineers and make customer bug reports unusable. That is a recurring operational cost, and prefix removal is a small, measurable lever against it. Frame the build/buy/fork decision in support hours saved per release, not developer convenience.
• Build vs. buy vs. reimplement. The capability is a narrow post-processing shim: detect PHP-Scoper's generated prefix and strip it from class-name strings. The realistic decision set is (a) adopt this package pinned, (b) fork it internally, or (c) write the ~20–50-line equivalent in the release pipeline. Given the artifact's profile — GPL-3.0, 10 stars, zero dependents, no release since 2021 — the PM call is which option keeps the pipeline owned, auditable, and license-clean.
• Roadmap signal, not a roadmap item. Strong opportunity signal against a weak artifact suggests the problem — readable diagnostics in scoped PHP distributions — is under-served, while this specific package is not a durable vehicle for solving it. If we ship multiple scoped artifacts, this is a candidate for an internal shared utility owned by the platform team, not a third-party dependency.
• License posture as a product constraint. GPL-3.0 is strong copyleft. Consumed strictly as a build-time dev tool that never enters the shipped artifact, exposure is confined to tooling. The credible usage pattern here — a runtime exception handler or Monolog processor that strips prefixes so production traces stay readable — embeds GPL code in the distributed output and propagates copyleft to the whole work. That is a distribution-terms decision for product and legal, and it gates every downstream hour of engineering.

When to Consider This Package

Consider it only when all of the following hold:

• We already run PHP-Scoper in a build pipeline and ship the resulting prefixed artifact to customers.
• Prefixed class names are demonstrably surfacing in user-visible or support-facing output — stack traces, exception messages, log lines, API error payloads, CLI output — and costing triage time.
• Legal has cleared GPL-3.0 against the actual consumption model (build-time-only vs. runtime-shipped). If any component ships inside the artifact, assume the artifact is GPL-encumbered until proven otherwise.
• A timeboxed spike confirms it works against our current PHP-Scoper version, our configured prefix literal, and our PHP 8.x CI image. Nothing unverified in a 2021 package should be assumed working.
• A named internal owner will pin, fork, and test it, because there is no upstream release cadence, no SLA, and no security disclosure process.

Look elsewhere — or write it in-house — when:

• We run a conventional Laravel application or a normal Composer-resolved package. PHP-Scoper is not in the picture, so the package has no role.
• Prefix removal can be expressed as a str_replace/preg_replace helper at our output boundaries. This is usually the better answer: no license exposure, no abandonment risk, no coupling to PHP-Scoper's non-public output format.
• We need configurability beyond a literal prefix — case-insensitive matching, regex rules, walking nested arrays or $_SERVER traces. Extension points are essentially nil; we would be writing the wrapper anyway.
• Legal cannot sign off on GPL-3.0 for the intended distribution model, or we cannot commit an internal maintainer.

How to Pitch It (Stakeholders)

To executives: This is a small cleanup utility for one specific distribution strategy — shipping self-contained PHP products with bundled dependencies. Its only value is making production errors readable again once we've protected our artifacts from dependency collisions. It is not a strategic dependency: it is a 2021-era, single-maintainer, GPL-3.0 package with 10 stars, zero dependents, and no release in four years. My recommendation is to treat it as a reference implementation rather than a dependency. The capability is roughly fifty lines of string handling, and we should own it in-house under our own license. That protects us from copyleft exposure and a bus factor of one at essentially no engineering cost.

To engineering: Low effort, low confidence. It is Composer-native, PHP-only, framework-agnostic, and tiny — integration cost is hours, not sprints. The constraint is provenance, not complexity: nobody has publicly validated it against PHP 8.2+ or current PHP-Scoper, and the package removes prefixes from strings handed to it, not from get_class() at the source, so don't expect transparent aliasing. If we adopt it, adopt it deliberately — require-dev or explicit scoped-build inclusion, exact version pin, invoked immediately after the php-scoper step, golden-file regression test in CI, and a smoke test that instantiates the remover via its scoped FQCN. The dominant engineering risk is fragility: prefix removal is literal string manipulation, and an off-by-one backslash produces a silent no-op while an over-broad pattern corrupts legitimate class names in ways that only fail at runtime inside a customer's install. The dominant non-engineering risk is license contamination if anything runtime-facing ships. Read src/ first — it's an hour — and settle build-time vs. runtime before spending integration time. Verify three things before committing budget: the package's PHP constraint against our CI image, the supported PHP-Scoper major/minor, and whether it consumes our existing scoper.inc.php or demands a parallel config that can drift.

Ask: Approve a one-day spike plus an early legal review of the GPL question as the gate. Expected outcome is a small internal helper in our release pipeline, with this package credited as the reference. Escalate only if the spike shows the in-house version is materially more complex than it appears.