Laravel Model Setting Laravel Package

Product Decisions This Supports

• Build vs. buy for per-record configuration. A package exposing a whereSetting() query scope implies settings stored alongside (or queryable with) Eloquent models. That lets you treat "settings" as a first-class, queryable part of your data model rather than scattering json_decode calls and ad-hoc whereJsonContains clauses through your codebase.
• Feature gating and entitlements. Query-time filtering by a setting value is what you need for plan-based access, per-tenant toggles, and staged rollouts ("show this to accounts where beta_ui is enabled"). This is a roadmap enabler: it makes per-account feature flags a data query instead of a config-file deployment.
• User and tenant preference filtering. Segments, digests, notification preferences, and locale/currency handling can be filtered in SQL rather than in PHP — relevant if you expect preference-driven list views or exports.
• Maintenance posture as a signal. 1.0.1 is a patch release that fixes a broken scope method. Two things follow: the whereSetting() scope is real, in use, and now behaves as documented; and the package is being maintained rather than abandoned. Both are inputs to a dependency-risk decision, not a feature decision.
• Upgrade decision. If anything in your stack pins 1.0.0 and relies on whereSetting(), that call path was returning incorrect results. Treat the bump to 1.0.1 as a bug fix to schedule, not a nice-to-have.

When to Consider This Package

Adopt when most of these hold:

• You already store model-level settings (JSON column or key/value side table) and are hand-writing query conditions against them in more than one or two places.
• You want the filtering logic to live in one tested scope rather than in controllers, repositories, and jobs independently.
• You are comfortable with a small, narrow-surface dependency — the API you would depend on appears to be a single scope method, which is cheap to replace later.
• You are on a Laravel version the package supports and can pin a version range in composer.json.

Look elsewhere when:

• You need typed settings objects with casting, validation, and encryption — spatie/laravel-settings is the better-known fit for that problem, and it solves a different one.
• You need feature flag evaluation at scale with targeting rules, audit history, and non-engineer controls — a hosted flag service will beat a database scope on both capability and operational cost.
• Your settings queries run against large tables. Filtering on a JSON column is index-hostile on many databases; if the scope compiles to a JSON predicate, validate the query plan under realistic row counts before committing.
• The package is single-maintainer with a thin release history. One patch release tells you it is alive; it does not tell you it is durable. If settings are on a critical path, prefer a package with a track record, or vendor the scope into your own codebase — it is small enough to own.
• You want configuration, not data. Laravel's config layer (with environment overrides and config caching) is the right tool for deploy-time values; reach for this package only for values that change at runtime and belong to a row.

How to Pitch It (Stakeholders)

A small, single-purpose Laravel dependency that makes stored settings queryable, so features like per-account toggles, plan-based access, and preference-filtered views become ordinary database queries instead of one-off code in each feature. It carries low lock-in: the surface area we would use is essentially one scope method, so the cost of removing it later is measured in hours, not sprints.

The latest release, 1.0.1, is a patch that fixes a bug in the whereSetting() scope — no new features, no breaking changes, no migration work. The practical read is that the package is actively maintained, and that anyone on 1.0.0 using that scope was getting wrong results and should upgrade.

Recommendation: worth a time-boxed spike in one service where we already hand-roll settings filtering. Success criteria are narrow — correct results, an acceptable query plan on production-sized tables, and a diff that deletes more custom query code than it adds. If the spike clears those bars, adopt; if the JSON filtering does not index well at our scale, we keep the pattern and drop the dependency.