Laravel Online Scope Laravel Package

Technical Evaluation

Architecture fit wotz/laravel-online-scope is an Eloquent concern, not a subsystem. It almost certainly ships a trait or a scopeOnline() local scope that constrains a model query to rows whose presence column (typically last_seen, last_activity, or last_active_at) falls inside a recency window. That places it squarely in the model/persistence layer with no service-provider wiring, no queue worker, no cache dependency, and no schema ownership. It composes with anything already querying the same table — dashboards, admin filters, whereHas relations — which is the main reason it is attractive: it standardizes a predicate that is otherwise copy-pasted across a codebase with subtly different TTLs.

Integration feasibility High and cheap. composer require plus one use statement on the model, with configuration likely limited to the column name and the TTL. The realistic integration cost is measured in hours, not sprints. The real work is not the install — it is confirming the package matches your existing presence data semantics and that your timestamp column is indexed.

Technical risk

• Zero adoption signal. 0 stars, 0 dependents, single author. There is no production track record to borrow, no issue history to read for known failure modes, and no community that has stress-tested edge cases. Treat the package as unvetted source code, not as a dependency.
• Bus factor of one. Release history is speculative; the April 2026 release date suggests either a very new package or a metadata anomaly. Either way, assume no SLA and no security response process.
• Semantic thinness. "Online" derived from a heartbeat timestamp is an approximation. It does not model explicit logout, multi-device sessions, WebSocket presence, or mobile background suspension. If the product's definition of online differs from "wrote a timestamp in the last N minutes," the scope will encode the wrong truth into every downstream query.
• Clock and timezone correctness. Any comparison of a stored timestamp against now() is a DST and UTC-storage bug waiting to happen. This is the single most likely source of silent, hard-to-reproduce defects.
• Naming collision. If the app already defines scopeOnline on a model, the trait either silently loses or produces a fatal method redeclaration depending on how it is written.
• Hidden query cost. A scope looks free at the call site. Applied to a large users table without a btree index on the presence column, it is a full scan disguised as a one-liner.

Key questions

1. Which Laravel and PHP versions are declared in composer.json, and is the constraint a caret range or pinned?
2. Does it publish a config file, and is the TTL configurable per model or globally?
3. Does it compare against now() in app timezone or UTC, and is that documented?
4. Does it exclude soft-deleted, deactivated, or unverified users, or is that the caller's responsibility?
5. Is there a paired offline / notOnline scope for the complement case, or will we write it anyway?
6. What transitive dependencies does it pull, if any?
7. How many lines of actual logic are inside it — is this a 20-line package we should simply vendor?

Integration Approach

Stack fit Fits any Laravel application that already persists a last-activity timestamp — session-authenticated monoliths, modular monoliths, admin panels, and internal tools. It does not fit stateless API services, event-driven architectures where presence lives in Redis or a presence channel, or systems where "online" is a first-class domain concept backed by its own table. The stack-fit question is really: do we already have the column, and do we already agree on what it means?

Migration path Because the abstraction is a single query predicate, adopt it behind a seam. Introduce an isOnline() / scopeOnline() contract on a base repository or a small domain trait and have that delegate to the package. If the package is later abandoned, vendored, or replaced with first-party code, the swap touches one file rather than every call site. This also lets you run the package and the hand-rolled predicate in parallel for a release cycle and diff the results — the cheapest possible correctness check given there are no dependents to learn from.

Compatibility Verify the declared Laravel constraint against the framework version actually pinned in composer.lock, not the version in the README. Check interaction with SoftDeletes (global scopes can mask the presence filter), withCount, eager loading, and pagination, since scopes that inject where clauses on joins can produce surprising counts. Confirm it does not register a global scope — a global presence filter on the User model would be a severe and silent behavioral change.

Sequencing

1. Spike (½ day). Read the full source — it is small enough to read end to end. This is cheaper than evaluating it as a black box.
2. Characterize (½ day). Write tests pinning boundary behavior at exactly TTL, at TTL−1s, and across a DST transition. If these tests are hard to write, that is itself the finding.
3. Decide build vs. buy. Given the likely line count, forking into app/Support/ or an internal package is a credible and probably preferable outcome. The license permits it.
4. Index first. Ship the index migration on the presence column before any scope goes live in a user-facing path.
5. Single-model rollout. Apply to one model, one endpoint, behind a feature flag. Compare against the legacy predicate.
6. Broaden. Roll out to remaining models only after the comparison window is clean.
7. Review at 30 days. Reassess the dependency against the fork on maintenance evidence, not on convenience.

Operational Impact

Maintenance Surface area is tiny, which is the saving grace: a package this small can be audited in an hour and forked in an afternoon. The maintenance burden is therefore low in engineering hours but non-zero in attention — someone must watch for Laravel major-version breaks, and with zero dependents there is no crowd to notice first. Recommend vendoring the logic and dropping the Packagist dependency once the behavior is characterized, unless the author demonstrates an active release cadence.

Support No community to lean on. StackOverflow will not have answers; there is no maintainer SLA. The escalation path is "read the source," which works here only because the source is short. That must be documented internally so the next engineer does not spend a day discovering it. Assign a named owner for the fork or the dependency — this package will otherwise become orphaned code inside the app.

Scaling The query shape (WHERE presence_ts >= ?) is index-friendly and scales well with a btree index on the timestamp column. The failure mode is not the predicate but its placement: applying it to a large user table inside a paginated list endpoint, or combining it with an ORDER BY on an unindexed column, produces sorts over large row sets. Online-count metrics should be computed once and cached with a short TTL rather than recomputed per request via the scope. Under high write volume on the presence column, expect index churn — consider a coarser bucket or a covering index if the table is hot.

Failure modes

• Timezone drift. Stored timestamps in UTC compared against a local-time now() produce users who appear offline during business hours. Highest-probability defect, hardest to notice in code review.
• Missing index. Silent performance cliff that appears only as the user table grows; not caught in staging.
• Config drift. Different TTLs across environments make "online" mean different things in staging and production, invalidating QA.
• Method collision. Duplicate scopeOnline produces either a fatal error at boot (loud, fine) or a silently shadowed scope (quiet, bad).
• Semantic rot. Presence rows go stale because logout or session-expiry hooks were never wired; the scope keeps faithfully returning an answer to the wrong question.
• Upgrade breakage. Laravel major version changes to Builder or Carbon silently alter comparison semantics with no maintainer to patch it.

Ramp-up Roughly one hour for any Laravel-proficient engineer to install, read, and apply. The organizational ramp-up is the larger cost: the team needs a shared written definition of "online" and an owner for the code, whether vendored or depended upon. Budget the definition work, not the integration work.