Settings Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a settings/configuration subsystem — verdict unchanged (build). A v2.0.0 has appeared, but the decisive signals from the prior assessment have not moved: still 0 stars, 0 dependents, still a single-maintainer, effectively dormant repository, and still no Laravel packaging. A version bump that only re-baselines framework requirements is not a "buy" option; it is a repo being kept installable, not a product being supported.
• Roadmap risk assessment — slightly clearer, still negative. The release narrows the compatibility window rather than widening it: Symfony >= 3.4 with no statement of support for Symfony 4.4 LTS, 5.x, or 6/7. If a settings module is on the roadmap, you still cannot de-scope the work by pulling this in. Budget internal engineering for schema, caching, validation, and an admin surface.
• Reference design, not dependency — reinforced. The autowiring change makes the bundle marginally more idiomatic to read (services declared by class, DI by type-hint) and therefore a slightly better design reference for a 1–2 hour skim during an internal spike. It remains documentation, not shipped code.
• Breaking-change relevance to us: none. Only support Symfony >= 3.4 is a breaking change for consumers on Symfony 3.0–3.3, and the autowiring switch breaks anyone who hand-wired or overrode service definitions. With zero dependents and no Laravel applicability, there is no migration exposure on our side — but it is a live demonstration that this package will make breaking changes without a deprecation path.
• Framework fit check — unchanged. Still a Symfony bundle, not a Laravel package. For a Laravel product it remains out of scope entirely, which settles build-vs-buy regardless of the release.
• Roadmap sequencing for settings-adjacent capabilities — unchanged. Per-tenant overrides, audit trails, encrypted secrets, feature flags, environment-scoped values: none are served here. Sequence them as first-class work.
• Use cases it would nominally cover, if it were viable: editable runtime configuration (site name, contact details, integration keys, feature toggles) stored in the database so non-developers can change values without a deploy, surfaced through an admin UI.

When to Consider This Package

Consider it only when all of the following hold:

• You maintain a legacy Symfony 3.4 application on PHP 7.x that cannot be upgraded on your current timeline. (Note the floor moved: 3.0–3.3 is no longer supported as of v2.0.0, and 4.x+ is still not addressed.)
• You need a minimal database-backed key/value settings store within the next sprint.
• You are willing to vendor/fork the code and own it permanently — accepting the dormant status, the 2018-era dependency constraints, and the absence of security patches.
• Your integration is compatible with autowired services (the v2.0.0 change); if you override or decorate service definitions by hand, budget migration work or expect breakage.
• The settings are internal, non-sensitive, and single-tenant (no secrets, no PII, no per-customer overrides).

Look elsewhere — or build — when any of these are true:

• You are on Laravel (this is a Symfony bundle and will not install or function) or on Symfony 4.4 LTS / 5 / 6 / 7 + PHP 8.1+ — v2.0.0 did nothing to extend the viable window forward, and a bundle still anchored to 3.4-era conventions will fight a modern container and attribute-based configuration.
• You need security-relevant settings: encrypted values, API keys, secrets rotation. An unmaintained dependency remains a supply-chain and compliance liability.
• You need multi-tenancy, per-user or per-environment scoping, audit history, or typed/validated settings beyond simple strings.
• You actually want feature flags (LaunchDarkly, Unleash, Laravel Pennant, Symfony's own tooling) or configuration management (Symfony Config, Dotenv, cloud parameter stores) — different problem, different tool.
• Your organization has dependency hygiene policy — 0 stars, 0 dependents, and one drive-by release will not survive review, and shepherding it through costs more than the ~200 lines of your own implementation.
• Reasonable alternatives exist: a single settings table with a cached repository, spatie/laravel-settings on Laravel, or craue/config-bundle / Symfony's parameter system on Symfony.

Bottom line: the adoption criteria are narrower after v2.0.0, not wider. The release is a compatibility re-baseline with a breaking change and no new capability, no maintenance commitment, and no forward support. The honest answer for the overwhelming majority of teams remains do not adopt. Watch whether any subsequent release follows within a reasonable window — a single bump does not establish a cadence, and one release is not the beginning of maintenance until a second one lands.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-evaluated hexanet/settings-bundle after its new 2.0.0 release and the recommendation is unchanged: do not adopt it. The release is a requirements bump, not a revival — it raises the minimum to Symfony 3.4 and modernizes service wiring, but adds no functionality, drops older Symfony versions without a deprecation path, and does not extend support toward Symfony 4.4 LTS, 5, or 6. The package still has no known users, no maintenance commitment, and no Laravel fit, so bugs or security issues would be ours to own indefinitely. The recommended path remains a small internal implementation (a few days of engineering) that we control and can extend toward multi-tenancy, auditing, and encrypted secrets. Net effect on the roadmap: no schedule savings from this dependency and no long-term maintenance liability.

For engineering (the short version):

• v2.0.0: Only support Symfony >= 3.4; services now autowired. Breaking for anyone on Symfony 3.0–3.3 or with hand-wired service overrides. Irrelevant to us — no dependents, no Laravel path.
• Still zero stars, zero dependents, dormant repo; still a Symfony bundle targeting PHP 7-era conventions, still no support statement for Symfony 4.4/5/6.
• Scope unchanged: basic DB-backed key/value settings with an admin surface. No encryption, no audit trail, no multi-tenancy, no meaningful typed validation.
• Action: do not add as a dependency. Optionally spend 1–2 hours reading the (now slightly more idiomatic) entity and autowired service design as a reference during our own design spike.
• Proposal: build a settings table + cached repository + typed accessors internally; revisit third-party options only if requirements grow into feature-flagging territory, where maintained SaaS/tooling actually exists.
• Watch item: if a second release follows shortly, re-open the evaluation; a single bump is not evidence of a support cadence.