Toggle Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance, and the v1.0.0 release does not resolve the central ambiguity. The package name and the Bundle suffix still indicate a Symfony bundle, not a Laravel package — expect a *Bundle class, a DI extension, and compiler passes rather than a Laravel service provider with config/toggle.php and facades. If the consuming stack is Laravel, this remains a port, not an integration. If Symfony, the idiomatic shape still fits: a bundle registering a feature-check service and resolving flags against a request-scoped "account" context.

What v1.0.0 changes. The release notes are a single line — "Initial release" — for a package that previously carried 0.x tags. That wording is itself a finding: it is either a repository re-creation, a history reset, or the first public tag of a previously private extraction. We cannot tell whether v1.0.0 is (a) a re-tag of the same 2021 code, (b) a rewrite, or (c) a genuinely new artifact under the same name. A major version bump with no changelog, no migration notes, and no diff summary is a documentation regression relative to a 0.x tag, not an improvement. The 1.0.0 semver claim does signal an intent to stabilise the public API, but intent is not a contract without a published changelog and a support commitment behind it.

Integration feasibility. The surface area still looks small and the intent narrow: given an account, answer "is feature X on?" — a single-service contract. The value still lives in the decision source (config, database, remote service) and the account resolution, both still opaque. v1.0.0 supplies no README, no usage example, and no dependents to copy a pattern from, so feasibility remains "read the source and find out." The one thing a fresh 1.0.0 tag may buy us is a cleaner source tree and current dependency constraints — verify that, do not assume it.

Technical risk. Still high, and the profile has shifted rather than improved. Provenance risk is unchanged (internal extraction from a product company's monolith, MIT, no security policy, no visible CI, no community to catch a CVE). Two new risks are introduced by the release itself:

1. Constraint tightening. A 1.0.0 almost always raises minimum PHP and Symfony versions. That makes installation on an older baseline harder, not easier, and may strand us between an old 0.x tag compatible with our stack and a new tag that is not.
2. Silent divergence. If v1.0.0 broke from 0.x, any example or fork we built against the old code is now stale, and there is no changelog telling us so. The only way to know the diff is to run it.

A feature-flag library sits on the authorization path of every request. A defect here is a permissions or availability incident, not a cosmetic bug.

Key questions.

1. Is the target stack Symfony or Laravel? Still the gating question, and still unanswered by the release notes.
2. What is the diff between the last 0.x tag and v1.0.0? Diff the trees directly; do not rely on "Initial release."
3. Did the composer.json constraints move — PHP minimum, Symfony major, Doctrine, PSR? This determines whether the package is installable at all on our baseline.
4. Is v1.0.0 a new repository/artifact or a re-tag of the 2021 code? Check commit history, author dates, and whether old tags still exist.
5. Where do flags live — config, Doctrine table, or remote service? Still opaque, and still the deciding factor for the failure model.
6. How is the account injected — interface, request listener, or global? Can it be adapted to our account model?
7. Does the 1.0.0 tag come with any stated support or patch commitment from Landingi, or is it a publish-and-walk-away?
8. Why does this exist rather than Unleash/Flagsmith/LaunchDarkly — is there capability here we cannot buy, or is it "it was already in their codebase"?

Integration Approach

Stack fit. Unchanged. If Laravel: do not integrate — porting a Symfony bundle's DI wiring, config tree, and compiler passes costs more than implementing account-scoped toggles directly, and yields a permanently unmaintainable hybrid. Use Laravel Pennant (first-party, maintained, scoped features built in) or a ~150-line internal service. If Symfony: installable via Composer, registered in bundles.php, configured through the extension's config tree — provided the new 1.0.0 constraints resolve against our baseline.

Migration path. Still: never let this package's API reach application code. Define our own FeatureResolver::isEnabled(string $flag, AccountContext $ctx): bool, implement it with an adapter over this bundle, and keep a config-driven implementation behind the same interface for tests and local dev. Half a day, and it converts an abandoned dependency into a swappable detail. This matters more now, not less: with a 0.x→1.0.0 jump and no changelog, the adapter is our only protection against an upstream break we cannot read about in advance.

Compatibility. Re-verify from scratch; the prior findings are void. Run composer why-not php ^8.3 and composer why-not symfony/framework-bundle ^7.0 against the v1.0.0 tag specifically, and check whether the old 0.x tag is still resolvable as a fallback. Given the historical 2021 baseline, expect v1.0.0 to have moved the floor up. If it fails on our stack, plan a vendored fork under our own namespace with constraints relaxed rather than pinning the application to an old baseline. The fork is still cheap because the package is small — that low surface area remains the one thing working in our favour.

Sequencing.

1. Diff audit (1–2 days, new first step): compare v1.0.0 against the last 0.x tag file by file. Establish whether this is a re-tag, a rewrite, or a new artifact. Read every file; write the missing README ourselves.
2. Constraint check (couple of hours, can run in parallel): confirm PHP/Symfony/Doctrine resolution on our current versions before any other work.
3. Sandbox spike: install v1.0.0 in a throwaway Symfony app, exercise one flag end to end.
4. Abstraction layer: land our FeatureResolver interface and a config-backed implementation first, so application code is written against our contract.
5. Fork and vendor if constraints fail, with a documented diff against upstream v1.0.0 pinned by commit SHA.
6. Pilot one low-risk flag on a non-critical path with a kill switch, before any authorization-relevant flag.
7. Expand or exit on pilot results; do not let this become load-bearing before step 6 proves out.

Operational Impact

Maintenance. Still effectively 100% ours from day one. A v1.0.0 tag does not create a maintainer. Zero stars, zero dependents, no visible CI, no security policy: no upstream to absorb bug fixes, dependency bumps, or security response. Budget a fork, a CI pipeline, and a named owner. Dependency drift compounds — the package's own Doctrine/PSR/Symfony contracts will accumulate advisories we cannot patch without touching the fork.

Support. Unchanged and unimproved. "Initial release" is not a support commitment. Landingi is a product company, not a library vendor: no SLA, no issue triage, no visible assignee ownership. Treat upstream as frozen and plan accordingly. If the v1.0.0 tag came with any statement of intent (a maintainer name, a roadmap, a CI badge), that is the single data point that would move this assessment — it is not present in the release notes provided.

Scaling. Flag evaluation still sits on the hot path of every request, so the decision source dominates. Database-resolved flags per account mean N+1 queries and cache stampedes under load — require in-request memoization plus a short-TTL shared cache with explicit invalidation. Remote-resolved flags make evaluation latency equal request latency — enforce a hard timeout and a documented default. Assume we are building the caching layer ourselves regardless of version.

Failure modes. The dangerous ones are silent and fail-open:

• Context missing — an unresolved account defaults to a permissive branch and exposes a feature to the wrong tenant.
• Evaluation exception swallowed — a check throws, a catch returns false, and a legitimate customer loses functionality with no alert.
• Stale cache — a flag flipped in the source of truth continues serving the old state, or flips mid-deploy.
• Post-upgrade behaviour change — the v1.0.0 jump has no changelog; a semantic change in account resolution or default handling is invisible until it manifests as wrong-tenant exposure.
• No kill switch for the flag system itself — if the resolver is a hard dependency, its outage is ours. Require a bypass path.

Instrument every evaluation with flag name and resolved value; alert on exception rate, not on individual failures.

Ramp-up. The code remains small enough that a mid-level PHP engineer reads the whole package in under a day. The cost is not complexity but the absence of documentation and the archaeology of inferring Landingi's account model — now compounded by an undocumented major version jump that forces a manual diff instead of a changelog read. Budget three to four days (one more than before) for a developer to reach confident, independent operation, plus the abstraction work.

Bottom line. v1.0.0 is a version number, not evidence. It changes one thing materially: it raises the probability that dependency constraints have moved up and away from our baseline, which makes install harder, and it removes the changelog as a way to understand what we are adopting. Everything else — zero adoption, no docs, no support, single-maintainer risk, hot-path blast radius — stands. Verdict unchanged: a weak primary dependency and a plausible reference implementation. If the stack is Symfony, the diff audit confirms a clean account-scoped contract, and the v1.0.0 constraints resolve on our versions, fork it, wrap it, and pilot one flag — the effort is small and reversible. If the stack is Laravel, if the constraints no longer resolve, or if the diff reveals a hard dependency on Landingi's internal entities or schema, stop and build or buy the twenty percent of this functionality we actually need.