Markable Laravel Package

Product Decisions This Supports

• Build vs. buy for Eloquent query logic. The package sits in the query-scope layer of a Laravel app (the v1.0.0 fix to a "wrong scope query call" indicates its surface area is reusable Eloquent scopes). That is normally 20–100 lines of in-house code, so the decision here is genuinely close: adopt only if the scope logic is non-trivial or duplicated across services.
• Roadmap sequencing for filtering/reporting features. Any feature that depends on consistent, composable query scopes (saved filters, list endpoints, admin reporting) can be scheduled without building the scope layer first.
• Dependency policy / risk budget. composer versioning at 1.0.0 is the substantive signal in this release: the package is now making a semver commitment, which converts it from "unpinnable pre-1.0 churn" to "safe to pin with a caret constraint." That is a procurement/governance decision, not just a technical one.
• Maintenance-health tracking. The scope-query fix is a correctness bug, not a cosmetic one — evidence the maintainer is actively finding and correcting defects. Worth logging as a watch item rather than a one-off evaluation.

Caveat: this assessment is derived from the v1.0.0 release notes alone. No API surface, docs, test coverage, or download/maintainer data was available at review time, so treat the scope-layer inference as a hypothesis to confirm before committing.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version and the package's scopes map to query patterns your team writes repeatedly.
• The scope logic is non-obvious enough that a shared, tested implementation beats a local helper (multi-tenant filtering, soft-delete interaction, permission-aware scopes).
• The 1.0.0 semver guarantee matters to you — i.e., you want to pin ^1.0 and be insulated from breaking changes.
• You have read the actual scope implementations and confirmed they are parameterized, index-friendly, and composable with where() chains rather than opaque.

Look elsewhere (or inline it) when:

• The scopes are thin wrappers you could own in a single trait — the dependency cost (upgrade cadence, security surface, one more maintainer to trust) exceeds the benefit.
• You need guarantees this release does not provide: an LTS branch, a security policy, or a documented deprecation window. A first 1.0.0 with a two-line changelog is a stability claim, not yet a track record.
• The package's query scopes would collide with existing global scopes or observables in your models — a "wrong scope query call" bug at v1.0.0 is a reminder that scope resolution order is subtle and worth validating against your model layer before rollout.
• You are on an older Laravel major that the maintainer has not declared support for.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a small Laravel query-scope package that just hit its 1.0 release. The practical upside is low and bounded — it replaces a small amount of hand-written query code with a maintained, versioned dependency. The practical risk is also low and bounded — the package is small enough to replace with in-house code in under a day if it stops being maintained. The 1.0 release is the meaningful event here: it comes with a semver commitment, which means we can pin it and stop worrying about breaking changes on minor upgrades. Recommendation: approve as a normal dependency, not a platform decision.

For engineering: The v1.0.0 changes are a correctness fix to a scope query call and the introduction of composer versioning. The fix is the more informative of the two — it tells us the package's risk is concentrated in query-scope resolution semantics, so our validation should focus there: confirm the scopes compose correctly with our existing global scopes and multi-tenancy setup before we depend on them in a list endpoint. The versioning addition means we can move to a ^1.0 constraint; no breaking changes are introduced by this release and no migration work is required. Before adoption, spend half a day reading the scope implementations and writing one integration test against a real model — if the scopes are thin wrappers around where() clauses, we should vendor them instead of taking the dependency.