Kit Bundle Laravel Package

Product Decisions This Supports

• Framework fit — the first decision is a scoping one. Despite the "Laravel/PHP" framing in earlier write-ups, survos/kit-bundle is a Symfony bundle, not a Laravel package. It has no service provider, no Laravel auto-discovery, and no Laravel facades. If our estate is Laravel, this package is out of scope and the build-vs-buy question never opens. If we run Symfony (or are evaluating it), this becomes live. Confirm which side of that line we are on before spending any more evaluation time — that single fact invalidates most of the prior assessment.

• Build vs. buy for bundle scaffolding. The capability is real but narrow: a base bundle that auto-registers routes, console commands, Twig namespaces, and AssetMapper paths by convention, plus shared entity traits, form types, and command utilities. That is exactly the boilerplate every in-house Symfony bundle re-implements. Buying it means adopting someone else's conventions; building it means a few days of work and full control. For a one-off project, build. For a team shipping several bundles, the convention layer is the reusable asset and the calculus shifts.

• Roadmap timing — pin it to a platform upgrade, not a feature. The only release note we have is 2.0.1 — "but really you need 8.1". Read correctly, that is a Symfony 8.1 floor, not PHP 8.1. Symfony 8.x is a very new major line with a correspondingly new PHP floor. So this package is a forcing function on our Symfony upgrade path: it cannot land before the framework move, and if it sits on a critical path it pulls that move forward. Plan zero product capability around 2.0.1; plan upgrade work around it.

• Dependency register and risk ownership. Adoption needs a pinned version, a named owner, and a documented upgrade path. The 0-star / 0-fork profile and single-maintainer pattern mean we are taking a concentration risk on a small vendor's release cadence. Register it explicitly rather than letting it slip in as a transitive dependency.

• Use cases it enables: (a) standardising a new Symfony service so every bundle looks the same from day one; (b) a Survos-based project where alignment with the maintainer's own conventions is the point; (c) a team already on Symfony 8.1 that wants to skip a week of scaffolding. Not applicable to Laravel services, and not applicable to any Symfony line below 8.1.

Caveat for the decision record: the 2.0.1 note is one sentence with no changelog, no migration guide, and no linked diff. Treat 2.0.x as unverified until engineering has installed it against our stack. This assessment should be revisited once a real changelog exists — and once someone has read composer.json rather than the prose.

When to Consider This Package

Consider it when:

• You are on Symfony, not Laravel. Table stakes. A Laravel codebase gets nothing from this.
• You are on, or imminently moving to, Symfony 8.1. Verify the actual constraint in composer.json — require.symfony/framework-bundle and require.php. The release note's "really you need 8.1" reads like a maintainer clarifying a floor the metadata may not state cleanly, and that gap is a diligence item in its own right.
• You are building more than one bundle. The value is the convention layer you stop re-writing, so it compounds across projects. One bundle? Write the twenty lines yourself.
• You accept the vendor profile. Pin the version, own the upgrade, and assume community-only support with no SLA. A timeboxed spike (install, run our suite, inspect transitive deps and licence) is cheap and should gate any commitment.
• Alignment with Survos conventions is a feature, not a coincidence. If we are deliberately adopting that ecosystem, convention match is the whole benefit.

Look elsewhere when:

• Your stack is Laravel. Different framework, different service container, different conventions. No partial overlap worth chasing.
• You are below Symfony 8.1. 2.0.1 is not for you. Either stay on a supported 1.x line — and confirm 1.x still receives fixes — or pick an alternative. Do not attempt a partial upgrade to reach this version.
• You need documented release discipline. A one-line release note is a signal about maintenance maturity. For regulated, security-sensitive, or long-lived products, weight that signal heavily: require a changelog, a security policy, and a disclosure process before adoption.
• The scaffolding is genuinely small for you. With thin release notes, code you control can be the cheaper long-run option — you pay once in hours rather than indefinitely in upgrade cadence.
• You need formal support terms. Absent a commercial backing entity, assume none.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small Symfony toolkit rather than building the same scaffolding in-house. Two facts decide it. First, it is a Symfony bundle — the earlier summary described it as a Laravel package, which was wrong, so this is relevant only to the Symfony side of our estate. Second, version 2.0.1 requires Symfony 8.1, a very new major release, and the entire release note is a single sentence saying so. That makes adoption a framework-upgrade question rather than a feature question: it is cheap for services already on the new line and blocked for everything else. With zero stars and one maintainer, I would not put it on anything business-critical until engineering has validated it. Recommendation: approve a short technical spike, no procurement commitment, and note that this only becomes a real decision if we are committing to Symfony 8.1 anyway.

For engineering (the ask): Answer four things in a day or two.

1. Framework and constraint: read composer.json and confirm this is a Symfony bundle (not Laravel), the actual symfony/framework-bundle constraint, and the actual php constraint. The release note says "really you need 8.1" — establish whether that is enforced in metadata or just asserted in prose, because that gap produces installs that appear to work and fatal at runtime.
2. Upgrade path: what breaks between 1.x and 2.x, and is 1.x still supported for anything we cannot move yet.
3. Convention surface: exactly what it auto-registers (routes, commands, Twig namespaces, AssetMapper paths) and how much of that fights with our existing bundle layout or CI.
4. Maintenance signal: commit cadence, test coverage, open-issue backlog, security policy.

Come back with a yes/no, a pinned version, and a one-line statement of what must be true on the platform first. Until that lands, this assessment stays provisional — a one-sentence release note is not enough to call it either way.