Barcode Bundle Laravel Package

Product Decisions This Supports

• Barcode capability scoping. Confirms barcodes are a commodity requirement, not a differentiator. Use this evaluation to close the "do we build barcode generation?" question fast: we don't, we consume a library. The scope decision that remains is which symbologies (Code128/EAN-13 for retail and shipping, QR/DataMatrix for tickets and asset tags) and where rendering happens (server-side PNG/SVG vs. client-side vs. embedded in PDF).
• Build vs. buy vs. adopt. This package argues against "adopt." Zero stars, zero dependents, and a last release of 2016-08-17 means no maintainer, no security response path, and no PHP 7.4/8.x compatibility story — a hard blocker for any Laravel app on a supported PHP version. The PM decision it informs is "buy the smallest maintained dependency," not "integrate a bundle."
• Framework standardization. It is a Symfony bundle (DI extension, service config, templating hooks), not a Laravel package. Adopting it would mean writing adapters to strip out framework coupling we don't use. This is a useful data point for the roadmap item "standardize on Laravel-native or framework-agnostic dependencies."
• Use-case prioritization. The underlying need spans several roadmap surfaces — inventory/stock labels, shipping and carrier labels, invoice and packing-slip identifiers, event ticketing and access control, asset tagging, retail POS and loyalty cards. Each has different fidelity requirements (quiet zones, print DPI, scannability at distance), so the PM decision is which surfaces ship first, not which library.
• Vendor/risk register entry. A 2016, single-maintainer, near-zero-adoption dependency belongs on the "do not onboard" list. Recording it prevents a future engineer from rediscovering it and quietly vendoring it in.

When to Consider This Package

• Realistically: only as a reference. If an existing Symfony 2/3 application already depends on it and you are doing maintenance-only work, evaluate a fork-and-pin rather than a migration — but treat that as technical debt with an owner and an exit date.
• Look elsewhere immediately if: you are on Laravel (any version — bundles do not load), PHP 7.4+ or 8.x, need QR/DataMatrix/PDF output, need a supported license and security disclosure channel, or need anyone to answer an issue. That covers essentially every scenario we have.
• Preferred substitutes, roughly in order: picqer/php-barcode-generator (framework-agnostic, actively maintained, SVG/PNG/HTML renderers) as the core; milon/barcode if the team wants a thin Laravel facade over it; endroid/qr-code or bacon/bacon-qr-code for QR/2D. All are drop-in at the same call sites, so switching later is cheap — which is itself the argument for not picking a dead package now.
• Verification gate before any adoption: confirm license compatibility, confirm PHP version support against our minimum, confirm the package emits standards-compliant output that scans on our target hardware (test with a physical scanner, not a screenshot).

How to Pitch It (Stakeholders)

Recommendation: do not adopt mwsimple/barcode-bundle. Take a one-sprint dependency on a maintained renderer instead.

For executives: barcode generation is table stakes, roughly a one-to-two-week integration, and carries no competitive advantage. The only real risk here is supply chain — a nine-year-old, unmaintained, unused-in-the-wild package with no security patch path is a liability we would inherit permanently for zero speed benefit. The maintained alternative is a single Composer line and costs the same to integrate.

For engineering: it's a Symfony bundle, so it doesn't fit our Laravel stack; zero dependents and no releases since 2016 mean no PHP 8 support and no upstream to patch. We propose picqer/php-barcode-generator behind a small internal BarcodeService interface so symbology and renderer choices stay swappable and testable.

The ask: approval to close this evaluation as "rejected — unmaintained and framework-mismatched," and to spend one sprint standing up the substitute behind our own interface, scoped to the first shipping surface (inventory/shipping labels) with QR deferred to phase two.