Visitor Tracking Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for request/visitor tracking. This bundle is a data point, not a solution. It confirms that "log every request to a table, expose a query layer" is a commodity capability with a well-understood implementation shape (a kernel/HTTP event listener feeding a persistence model). That removes any justification for paying a vendor premium for basic traffic logging, and equally removes any justification for taking on a third-party dependency to get it.
• Scoping an internal audit trail or lightweight analytics feature. If the roadmap contains "who accessed what, when" — internal admin auditing, per-tenant traffic visibility, support-facing "last seen" data — this repo is useful as a requirements reference: what fields to capture (route, method, IP, user agent, timestamp, session/user linkage), where to hook into the request lifecycle, and how to keep the write path off the critical path.
• Roadmap de-risking. It is archived, last shipped October 2020, has 10 stars and zero dependents. Any roadmap item that assumes this package as an implementation dependency is implicitly unowned. Naming that early prevents a plan that quietly depends on dead code.
• Ecosystem-fit filtering. Despite being framed as a Laravel/PHP package, it is a Symfony bundle. For a Laravel codebase, adoption would mean fighting the framework boundary for a capability Laravel middleware provides natively in a day. This is a concrete example of "PHP package" ≠ "fits our stack," which is worth encoding as a standing evaluation criterion.
• Privacy/compliance gap identification. The feature space it touches (IP addresses, user agents, session identifiers) is personal data. A 2020-era, unmaintained bundle carries no evidence of consent handling, IP anonymization, retention policy, or PII redaction. That's a requirements checklist to attach to whatever we build instead — and a reason to prefer a managed vendor if compliance burden is material.

When to Consider This Package

Consider it only as a read-only reference — a worked example of structuring a Symfony request-tracking listener and entity. The MIT license permits lifting patterns freely. Budget an hour of engineering reading time, not an integration sprint.

Look elsewhere — or build — when any of the following is true:

• You are on Laravel. You are not the target framework. A middleware + Model + migration is the native path; adapting a Symfony bundle is strictly more work for less fit.
• You need a maintained dependency. Archived with no release since 2020 means no Symfony major-version compatibility, no security patching, no upstream response to CVEs. For a capability that writes to your database on every request, that's an unacceptable supply-chain position.
• You need production analytics. No evidence of dashboards, aggregation, bot filtering, retention/rollup, sampling, or async write handling. A per-request synchronous DB write is a scalability liability under real traffic; the interesting engineering (queueing, batching, partitioning) is absent.
• You need compliance guarantees. GDPR/CCPA handling, consent gating, and IP anonymization must be designed in, not bolted on.
• You need a support contract or an owner. Zero dependents and a single-digit star count mean no community to inherit maintenance if the original author walks away — which they have.

Viable alternatives by decision type: managed analytics vendor (Matomo, Plausible, Fathom) if the need is genuine product analytics; Laravel's first-party tooling (Telescope, request logging, rate-limit/cache primitives) if the need is operational debugging; a ~1–2 day in-house middleware if the need is an internal audit trail or tenant traffic counting.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Use as design input only.

This package solves a real but commoditized problem — recording HTTP requests for later analysis — and it solves it in Symfony, not Laravel. More decisively, it is archived, unmaintained since October 2020, with no downstream dependents. For a component that would sit directly in our request path and write to our database, we would be inheriting 100% of the maintenance and security risk for roughly zero differentiated value.

The cost calculus is simple: integration and adaptation effort exceeds the effort of writing the equivalent Laravel middleware ourselves, while the long-term liability is strictly higher. There is no version where adopting this is the cheaper option.

What we take from it: a validated feature shape and a requirements checklist — capture fields, hook point in the request lifecycle, and the privacy obligations (IP anonymization, retention, consent) that a 2020-era package does not address and that we must. Engineering estimates an in-house equivalent at 1–2 days for an internal audit trail, with full control over async writes and data handling.

Ask: approve the small in-house build (or a managed-vendor evaluation, if the need is product-facing analytics rather than internal auditing) and close out this package as evaluated-and-rejected. The MIT license means we lose nothing by reading its patterns; we simply shouldn't ship its code.