Phpqrcode Bundle Laravel Package

Technical Evaluation

Architecture fit — wrong ecosystem glue, and that is the decision. Despite being catalogued as a Laravel/PHP package, jonasarts/phpqrcode-bundle is a Symfony bundle. It ships a Bundle subclass and Symfony DI service/extension definitions; Laravel does not register Symfony bundles (it consumes Symfony components, not bundles), so there is no service provider, no facade, no vendor:publish, and no auto-discovery path. What is genuinely under evaluation is the wrapped upstream library — Dominik Dzienia's pure-PHP phpqrcode port of libqrencode — which is mature-but-old procedural code. As a TPM the framing matters: you are not buying a capability, you are buying ~50 lines of container glue targeted at a framework you do not run.

Integration feasibility — low as a dependency, moderate as a source. The bundle does little beyond binding QRcode::png() into a container and exposing config for size, error correction, and margin. The real logic lives upstream, where the encoder is procedural, un-namespaced (QRcode, QRencode, QRimage globals), and rasterizes PNG via GD. In a Laravel app those global classes are a collision and autoload hazard. Realistic options are: (1) adopt the upstream encoder and wrap it in our own Laravel service provider, (2) fork the bundle's wrapper logic, or (3) replace with a maintained PSR-4 encoder. Only option 3 is a defensible default; this package is best treated as a reference implementation.

Technical risk — high, concentrated in upstream abandonment. Signals are unambiguous and mutually confirming: 6 stars, 0 dependents, opportunity 28.9, overall score 0.12. The underlying encoder has been effectively dormant for roughly a decade, and the bundle inherits that posture. Concrete risks:

• PHP 8.x compatibility is unverified; legacy procedural syntax is a standing source of deprecations and fatals on minor upgrades.
• GD is a hard dependency — an Imagick-only or GD-less host fails fatally rather than degrading.
• Global namespace collision with any other package vendoring phpqrcode (common in legacy code); surfaces under specific load orders, i.e., in production rather than CI.
• No community backstop — no issue triage, no security advisories, no downstream canaries. We are the canary.
• License is clean (MIT for the bundle), so forking is legally unencumbered — the risk is engineering, not legal.

Key questions before any commitment:

• Which PHP and Symfony versions does composer.json declare, and does it install cleanly on our runtime?
• Does the wrapper expose error-correction level, module size, quiet zone, and encoding — or hardcode them?
• Is output raster-only (PNG), or is any vector/SVG path available?
• Are there existing production QR artifacts whose byte-level output we must preserve, or is any valid scannable code acceptable?
• Is there any business reason to prefer this over bacon/bacon-qr-code, endroid/qr-code, or chillerlan/php-qrcode?

Integration Approach

Stack fit — replace, do not adopt. For a Laravel roadmap the target is a PSR-4, maintained encoder: simplesoftwareio/simple-qrcode (wraps bacon/bacon-qr-code; Laravel-native facade and publishable config; PNG and SVG) for the fast path, or chillerlan/php-qrcode where we want zero framework coupling. If a Symfony service is genuinely in scope elsewhere, endroid/qr-code is the maintained equivalent and is itself a real bundle — unlike this one.

Migration path. QR output is a standardized artifact; only rasterization, margin, and error-correction choices differ. That makes an encoder swap low-blast-radius, provided we contract-test scannability rather than pixel equality. Pin current outputs, regenerate the same payloads with the candidate, decode both with a scanner library (e.g., zxing) across sizes and print DPIs, then diff pass/fail. Payload strings and the service contract are unchanged; only the adapter behind them moves.

Compatibility. Verify against our actual matrix — PHP version, GD versus Imagick, and whether generated files must land on S3 or local disk. The bundle's Symfony version constraints are irrelevant to a Laravel target and would only add phantom transitive dependencies if pulled in.

Sequencing.

1. Spike (1–2 days): attempt composer require on our runtime and document the failures; confirm the GD and global-namespace findings empirically.
2. Decide: default to replacement with a maintained encoder; adopt the upstream encoder only if a hard constraint (byte-identical legacy output, air-gapped registry) forces it.
3. Adapter: define a single QrCodeGenerator interface in the domain layer so the encoder is swappable and never leaks into controllers.
4. Contract test + rollout: scannability suite in CI, then ship behind the interface.

The interface-first step is the TPM-relevant move: it converts a vendor-lock question into a one-file change later.

Operational Impact

Maintenance — we would own it. Upstream is dormant with zero dependents, so no ecosystem patches our bugs. Budget either a vendored fork under our namespace with a named owner, or avoid the cost by choosing a maintained encoder. The latter is cheaper over any horizon past a few months, and this is the line item where the recommendation is most defensible to finance.

Support. No community, no triage, no advisories. Engineers debugging un-namespaced procedural code move slower than on a documented PSR-4 library, and onboarding material is ours to write. There is no vendor to escalate to and no versioning policy to reason about.

Scaling. Encoding is pure-CPU PHP work, typically 1–10 ms per code depending on payload and module size; the GD PNG encode dominates. At real volume: cache aggressively keyed on hash(payload + ec_level + size + margin), pre-generate static codes at build time, and serve from CDN or object storage. Never generate the same QR twice. Cap payload length at the interface boundary so long URLs and vCards cannot inflate version and CPU unpredictably.

Failure modes to instrument:

• GD absent or Imagick-only host → fatal, not exception. Validate at boot, not at first request.
• Unwritable temp/output path → silent or partial writes. Validate paths at startup.
• Global QRcode class collision → fatal only under specific load orders; catches CI only if we test the full dependency graph.
• Unscannable output from a too-small quiet zone or low error correction on printed media — a product-visible defect, not a crash, and the one that reaches customers.
• PHP minor upgrade breaking legacy syntax — untested upstream, so treat every PHP bump as a regression event for this dependency.

Ramp-up. The wrapper itself is trivial; the cost is the absence of conventions. Expect roughly a day for an engineer to trace the procedural call chain and half a day of review for anyone touching it cold — versus near-zero for a documented PSR-4 encoder with published examples.

Recommendation. Do not adopt jonasarts/phpqrcode-bundle as a dependency in a Laravel codebase: it is a Symfony bundle wrapping an abandoned encoder with no adopters. Use it only as a fallback if the spike surfaces a hard compatibility constraint, and in that case fork the encoder into our own namespace behind a QrCodeGenerator interface. The default path is replacement with a maintained encoder — the risk delta is large, the integration effort is comparable, and the switching cost later is one adapter class. Ask: approve the interface-first approach and a short spike against a maintained library; reject this package as a direct dependency.