Qrcode Library Laravel Package

Product Decisions This Supports

• QR-code features across the product surface — ticket/entry codes, two-factor enrollment, sharing links, event badges, invoices, Wi-Fi onboarding, and contact cards. The package covers PNG/JPG/SVG generation plus vCard/MeCard output, so most "generate a scannable code" roadmap items can be built on top of it rather than invented.
• Build vs. buy: adopt, don't build. QR encoding, error correction, and image rendering are commodity problems with mature open-source coverage. Reusing this library avoids a bespoke implementation and the maintenance burden that comes with it.
• Infrastructure simplification. The 4.0.0 GD-native renderer means PNG/JPG output no longer requires ImageMagick (ext-gd only). That removes a system-level dependency from Docker images, CI, and Windows dev/ops environments (the release fixes the Windows CoderModulesPath failure). A viable roadmap item is "retire ImageMagick from our runtime images."
• Contact-sharing use cases. vCard PHOTO (Base64/data-URI/local file) and MeCard ORG extend what we can ship in "save my contact" and event-badge flows without custom serialization work.
• Framework reach. The new PSR-15 QrCodeAction (Yii3, Mezzio, Slim, any PSR-15 app) is useful if we run services outside Laravel or want to share QR behavior across a polyglot estate. For a Laravel-only shop this is nice-to-have rather than decisive.

When to Consider This Package

• PHP 8.3+ is a hard prerequisite. 4.0.0 drops support for < 8.3. If any service is pinned below 8.3, that service must upgrade PHP before this version is adoptable — treat it as a dependency of the PHP modernization work, not an independent choice.
• Server-side generation fits your needs. If you need QR codes as downloadable/embedded images (PDFs, emails, print assets), this is the right shape. If you only need client-side/JS-rendered codes in the browser, a JS library is a better fit and lighter.
• You want zero-ImageMagick deployment. GD-native PNG/JPG is a strong reason to adopt 4.0.0 specifically; staying on 3.x keeps the ImageMagick requirement.
• Consider alternatives when: you need very high-volume rendering where a managed API offloads scaling; you need specialized output (native PDF vector embedding, EPS, etc.) beyond image formats; you are on a legacy PHP version with no near-term upgrade path; or you need only trivial, low-fidelity codes where a tiny dependency is preferable.
• Breaking-change cost is real. 4.0.0 moves adapters to Da\QrCode\Bridge\<Framework>\, renames StyleManager::getGradientTye() → getGradientType(), changes QrCode::getGradientType() to return a GradientType, drops marc-mabe/php-enum, and bumps bacon/bacon-qr-code to ^3 and khanamiryan/qrcode-detector-decoder to ^2. Adoption should be scheduled as a deliberate migration, per the Upgrade Guide.

How to Pitch It (Stakeholders)

For executives: This release lets us offer QR-based features (tickets, 2FA, contact cards, event badges) on a well-maintained open-source library, and it removes a system dependency (ImageMagick) from our deployment stack — lower ops risk, simpler environments, less to patch. It's a major version with breaking changes, so the cost is an engineering migration, not a rewrite.

For engineering: 4.0.0 modernizes the package: PHP 8.3/8.4/8.5 with a CI matrix, PHPStan and php-cs-fixer v3, GD as the default PNG/JPG backend (ImageMagick now opt-in), a framework-agnostic PSR-15 bridge, and fixes for gradient rendering and the standalone Laravel QrCodeFactory. Upgrading from 3.x requires following UPGRADE-4.0.md: update adapter imports to the Bridge\<Framework> namespaces, adjust gradient-type call sites, and re-run dependency resolution against the bumped bacon/bacon-qr-code and detector libraries. Plan it as a scoped migration with a test pass over every QR output path before rollout.