Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Php User Agent Bundle Laravel Package

exs/php-user-agent-bundle

Symfony bundle that wraps donatj/PhpUserAgent. Register EXSPhpUserAgentBundle, then call PhpUserAgentService::parseUserAgent() on a user-agent string to detect platform, browser, and browser version. Simple service-based access with no extra configuration.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Feature scoping for UA-dependent capabilities. This package enables the classic "read the User-Agent string" feature set: browser/platform/version detection for analytics segmentation, adaptive rendering, default-locale or download suggestions, and coarse support-tier messaging. Any roadmap item that starts with "we need to know what browser the user is on" lands here.
  • Build vs. buy at the smallest possible unit. The bundle is glue code, not technology. The actual parsing logic lives in donatj/PhpUserAgent. The real decision is not "adopt this bundle" — it is "do we call a third-party parser, or hand-roll regexes?" (Call the parser. Always call the parser.)
  • Dependency posture for legacy Symfony estates. Useful as a signal when auditing an older Symfony 2.x codebase: it tells you the team was already outsourcing commodity concerns and prefers thin wrappers. That's a good cultural signal for future buy decisions.
  • Deprioritization input. The dependency chain is one global-function library with no device-type, bot-detection, or Client Hints support. If the roadmap includes bot filtering, device-class targeting, or future-proofing against UA string deprecation (Chrome's frozen UA, Sec-CH-UA), this package answers none of it — which is itself a decision: don't scope those features assuming this foundation.
  • Not a build-vs-buy lever at the platform level. At 1 star, 0 dependents, and README-level maturity, it should not influence architecture standards. It's a data point, not a precedent.

When to Consider This Package

Consider it only when all of these hold:

  • You are on Symfony 2.x (the README's AppKernel registration is the giveaway) and cannot easily adopt modern autowiring.
  • Your need is genuinely trivial: browser name, platform name, version string. No bot detection, no device class, no crawler filtering.
  • You want a copy-paste install and are comfortable that the "integration" is a single class you could write yourself in under 20 lines.
  • You accept the maintenance risk: single-vendor package, no visible test suite, 0 dependents, and a typo (getFlatform()) baked into the public API — a strong tell that no consumer has ever pushed back on the interface.

Look elsewhere in every other case:

  • Modern Symfony (4/5/6/7): register the service yourself or bind the underlying library. This bundle adds a registration step and a custom service class in exchange for zero configuration convenience.
  • You need real detection: use matomo/device-detector (device type, bots, brand/model, active maintenance) or whichbrowser/whichbrowser.
  • You need future-proofing: no PHP UA-string library solves Client Hints; plan for Sec-CH-UA headers alongside any parser.
  • You need vendor accountability: 1 star and 0 dependents means no community backstop, no security review trail, and no one else to hit the bugs first. For a component that sits on every request path, prefer a dependency with a visible issue tracker history.
  • If you do want this exact behavior: depend on donatj/php-user-agent directly. You get identical output, one fewer layer, one fewer maintainer, and you control your own DI wiring.

How to Pitch It (Stakeholders)

One-liner for executives: A small, MIT-licensed Symfony wrapper around a user-agent string parser — cheap to adopt, but low-maturity, and it solves only the simplest version of the problem.

The recommendation: Do not adopt the bundle as a dependency. If we need UA parsing, take the underlying library (donatj/php-user-agent) or a stronger alternative (matomo/device-detector) directly, and write our own service registration — roughly a half-day of work that removes a single-vendor dependency from our request path.

The business case in three points:

  1. Cost is trivial either way. MIT license, one small package. The differentiator is not price, it's risk.
  2. Risk is concentrated. One maintainer, one star, zero dependents, no test suite, Symfony-2-era API, and a misspelled public method. A dependency on the hot path should have a community behind it.
  3. Scope is narrower than it appears. Browser/platform/version only. No bot detection, no device class, no Client Hints. If the roadmap needs any of those — and user-agent strings are being frozen by major browsers — this becomes throwaway work.

For engineering: treat this repo as a reference implementation, not a dependency. It demonstrates the correct pattern (wrap the library, expose a narrow service) in about 30 lines. Copy the pattern, skip the package.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log
gregsphotography/site-builder-components
io-digital/clickatell
snowsoft/laravel-admin
oxygen/auth
relicsoftware/barakah-payment-gateway
tobya/work-with-composer
equipc/laravel-email-validator
equipc/laravel-email-database-log
adedsec/nova-translated-labels
wazza/laravel-db-encryption
hokny/laravel-generator
vonsogt/backup
jengo/queues
jeremykenedy/laravel-observability
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums