Nova Qrcode Field Laravel Package

Product Decisions This Supports

• Feature scoping — "show a QR inside admin" vs. "build QR capability." This package answers a narrow question: can we render a scannable code on a Nova resource detail view without custom Blade/JS? If that is the entire requirement — asset tags, check-in passes, invite links, location codes, support handoffs, admin deep links — this is a one-line field registration, not a sprint. If the requirement is customer-facing QR with branding, expiry, analytics, or batch export, this package does not answer it and should not be evaluated as if it might.

• Build vs. buy. This is at the extreme "buy" end: MIT-licensed, single-purpose, one Composer require, no migrations, no service to operate. The build alternative (a custom Nova field wrapping endroid/qr-code or bacon/bacon-qr-code) is maybe a day of work but is a day we then own forever. The honest framing is that the buy decision here is small and reversible, which is precisely why it's worth making quickly rather than debating. It is not a platform commitment.

• Roadmap prioritization. Best classified as internal productivity/operational tooling, funded out of existing admin work rather than a roadmap line item. It should not displace customer-facing work. The one exception: if QR-based admin workflows measurably unblock field operations, support response time, or asset reconciliation, then it earns a small, time-boxed slot — and the metric to watch is whether admins actually scan, not whether the field renders.

• Use-case validation and cheap prototyping. Low cost to pilot: put it on one detail view, scan it with a phone, confirm the payload is exactly right. That single test validates whether the workflow is worth pursuing at all — cheaper than user research on a hypothetical.

• Dependency posture. Adopt opportunistically, pin ^2.0, and wrap the field behind a local class so a fork or replacement is a one-line change. Signals are mixed: v2.0.6 (July 2025) added Laravel 12 support, which shows the maintainer tracks framework releases — but 46 stars, 0 dependents, and a release note that says nothing about Nova majors mean we should assume we may be the most demanding consumer of this package.

• Security and scope boundaries. The field renders plain text. Anyone who photographs the screen has the payload. That is a product constraint, not an implementation detail: it rules out API keys, credentials, PII, and long-lived sensitive links, and it means sensitive flows must encode short-lived signed URLs or one-time tokens generated by our application, not by the field.

• Where the domain logic lives. The package is a display component. What gets encoded, how long it lives, and who may scan it remain application concerns. That boundary keeps the dependency cheap to remove and keeps the QR from quietly becoming a source of truth.

When to Consider This Package

Consider it when:

• Laravel Nova is already installed, licensed, and central to your admin surface — the package is worthless without it, and Nova's private Composer credentials must already be working.
• The use case is internal, admin-facing, low-risk, and reversible: asset labels, check-in/onboarding links, support handoffs, location codes, record deep links.
• You are on a modern Laravel/Nova stack and can verify Nova major-version compatibility directly (from the package's composer.json constraint and an actual render), rather than inferring it from the Laravel 12 release note.
• You want a proof of concept this week and are willing to read a small src/ directory, pin the version, and wrap the field behind your own class.
• MIT licensing, a minimal dependency surface, and no vendor relationship are acceptable — and you accept that maintenance may stall without notice.

Look elsewhere when:

• You are not on Nova. There is no partial value here; the entire package is a Nova field.
• You need customer-facing QR: branded codes, expiry, revocation, scan analytics, high availability, batch generation, or an SLA. That is a QR service decision, not a field decision.
• Payloads are security-sensitive — payment links, PII, credentials, regulated data — and require audit, review, or vendor support.
• You need downloadable or printable assets at volume. Don't scrape the rendered output; use a general PHP QR library in a Nova Action and stream the file. If print pipelines are the real requirement, this package is the wrong starting point.
• Your organization requires meaningful adoption signals, maintainer guarantees, or a support contract. 46 stars and 0 dependents do not meet that bar, and no amount of reading the changelog changes it.

How to Pitch It (Stakeholders)

For executives. This is a small, MIT-licensed Laravel Nova field that puts a QR code on internal admin records — asset lookups, support handoffs, check-in passes, admin deep links. It is not a strategic platform bet and should not be framed as one. The value is low-cost workflow acceleration inside tooling we already operate: roughly a Composer require plus a field line, no new service, no new vendor. The July 2025 release added Laravel 12 support, which reduces upgrade friction, but adoption is minimal — we would be an early consumer. Recommendation: approve it for internal, reversible use cases only, wrapped behind our own abstraction and version-pinned so it can be swapped out cleanly. Do not let customer-facing or security-critical QR workflows depend on it; if that need appears, it deserves its own scoped decision.

For engineering. Treat this as a narrow Nova UI field, not a QR platform. Before adopting: confirm Nova compatibility by reading the laravel/nova constraint and rendering once in a real panel; confirm PHP constraints; determine whether rendering is client- or server-side, because that dictates whether we worry about CSP and published assets or about CPU and caching; and check whether any publish step is needed (an empty box after an upgrade is usually missing assets). Then constrain it: ->onlyOnDetail() — never on index, where Nova resolves fields per row and QR generation is CPU-bound; compute dynamic payloads lazily via resolveUsing() or a model accessor rather than on every request; pair the QR with a copyable text field so a human can grab the string; and never encode secrets, PII, or long-lived sensitive links — use short-lived signed routes or one-time tokens instead. If we need downloadable or printable assets, build that separately in a Nova Action with a standard QR library rather than scraping the rendered component. Finally, wrap it (class QrCode extends \Devtical\NovaQrcodeField\Qrcode {}) and pin ^2.0 so a replacement or fork is a one-line change, and test the underlying attribute/accessor rather than snapshotting QR pixels.