Filament Barcode Field Laravel Package

Product Decisions This Supports

• Scan-to-fill in admin/back-office forms: The primary decision this enables is whether to add camera-based barcode capture to Filament resource forms (product intake, inventory counts, receiving/shipping, asset registration, sample or specimen tracking, returns processing). It is a form field, not a scanner app — value depends entirely on whether operators currently hand-key 8–13 digit codes on phones or tablets.
• Build vs. buy for a single field: The package is roughly one class (BarcodeInput extends TextInput), one Blade view, and a config file wrapping the html5-qrcode library. That makes the real decision "adopt, vendor, or reimplement," not "platform or not." Any in-house alternative carries the same underlying dependency; this package mostly saves the Filament-specific glue (asset registration, translations, placeholder behavior, modal wiring).
• Hardware vs. camera workflow: It does not replace USB/Bluetooth keyboard-wedge scanners — those emit keystrokes and already work with a plain TextInput. Adopt this only for the scenario where the device is the camera (field staff phones, tablets at a receiving dock, no dedicated hardware).
• Symbology scope as a roadmap gate: Supported formats are 1D only (EAN-13/8, UPC-A/E, Code 128/39, ITF, Codabar). Notably no QR, Data Matrix, or PDF417. This directly decides which roadmap items this can serve (retail/GTIN, logistics cartons, library/asset tags) and which it cannot (2D labels, GS1 DataMatrix on pharma/healthcare, most modern QR-driven workflows).
• Localization readiness: 17 locales shipped in 1.1.0 signals the field's placeholder/modal copy is safe for non-English operator bases without custom translation work — relevant if you're rolling out to multi-region warehouses.
• Config-driven tuning as a product lever: Restricting formats to the 1–2 symbologies you actually use measurably improves scan speed and reliability. Treat "narrow the formats list" as a launch checklist item, not a nice-to-have.

When to Consider This Package

Consider it when:

• You are on Filament v5 (package 3.x; note the docs table maps 1.x→Filament 3, 2.x→4, 3.x→5 — verify the tag you install matches your Filament major, since the latest release note is 1.1.0 while the skill's install line says ^3.0).
• Your capture workflow is camera-on-mobile-device and your codes are 1D retail/logistics symbologies.
• You need a low-effort, low-risk addition and are comfortable with a package whose entire surface area you could fork in an afternoon.
• You want built-in i18n and a Filament-native look (modal width, reader dimensions, FPS all configurable) rather than a bespoke Alpine component.
• You can vendor or pin the package and accept ownership of it — MIT license means forking is legally and technically cheap.

Look elsewhere when:

• You need 2D codes (QR, Data Matrix, Aztec, PDF417) or GS1 application-identifier parsing — you'll need BarcodeDetector/ZXing/a 2D-capable library, not this.
• You need server-side barcode generation/rendering (labels, PDFs). This package reads codes; it does not produce them.
• Your environment has a strict Content Security Policy or no external CDN egress — asset_js defaults to https://unpkg.com/[email protected]/..., a third-party runtime dependency and supply-chain consideration. Self-host the JS or budget for that change.
• Vendor support and SLAs are required. Signals here are thin: 4 stars, 0 dependents, single maintainer, no downstream usage to de-risk against. Bus factor is the dominant risk, not code quality.
• You require scan validation (check-digit verification, GTIN formatting, duplicate detection). It's a TextInput, so you get Filament validation, but all domain validation is yours to write.
• Non-HTTPS or locked-down devices are in scope — camera access requires HTTPS and user camera permission, which is a support burden in managed-device fleets.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component that lets operators scan a barcode with a phone or tablet camera directly into a form field, instead of typing the number. The business case is error and time reduction on manual code entry in inventory, receiving, and asset-tracking screens — a narrow, well-understood win rather than a platform bet. Cost is near zero (one Composer dependency, config-only setup), and because the whole component is ~1 class plus a view, we can take ownership of it outright if the upstream project stalls.

For engineering: It's a Filament v5 form component extending TextInput, wrapping html5-qrcode via CDN and restricted to eight 1D symbologies. Integration is composer require, publish config, drop BarcodeInput::make('barcode') into a schema. Three things to own explicitly: (1) pin the version and confirm the Filament major mapping — version tags and the docs table don't line up cleanly; (2) self-host or whitelist the html5-qrcode CDN URL and add it to CSP, since it's a third-party script loaded at runtime; (3) narrow the formats array to the symbologies we actually scan, and add our own checksum/GTIN validation on top. Treat the dependency as vendorable — the fork cost is trivial and it removes the only real adoption risk (a 4-star, single-maintainer project with no downstream users).