Fw Bundle Laravel Package

Technical Evaluation

Architecture fit — and a stack mismatch to resolve first. The supplied description says "Symfony bundle for framework 7," and the repository source confirms it: src/SurvosFwBundle.php, templates/, translations/, assets/, public/, and an AssetMapper registration. This is a Symfony bundle, not a Laravel package. The Laravel-oriented evaluation material in this packet is boilerplate generated without reading the source and should be discounted entirely; any assessment that talks about extra.laravel.providers or php artisan vendor:publish is describing a different artifact. The package's actual shape is:

• An opinionated Survos bundle that wires Framework7 (mobile UI) support into a Symfony app.
• Twig base templates and components (fw-base.html.twig, start.html.twig, components/) as the UI contract.
• A Stimulus controller (@survos-mobile/mobile) registered through AssetMapper/importmap, intended to be subclassed by the consuming app's app_controller.js.
• A dependency on survos/kit-bundle and a stated direction of tracking Symfony 8.1 (including betas) via the AbstractUxBundle pattern.

So "architecture fit" is a narrow question: does a team building a Symfony app with a Framework7 mobile front end, using AssetMapper and Stimulus, and willing to accept Survos conventions get more value from this than from writing the same ~a few hundred lines of Twig/Stimulus glue themselves? Given the size of the surface, that is a genuinely open question, and the honest default answer is "probably not, unless we are already inside the Survos ecosystem."

Integration feasibility. Mechanically easy: Composer install, bundle registration, an importmap entry, and Twig namespace resolution. Feasibility, however, hinges on four checks that must be completed before any commitment:

• Symfony version constraint. The maintainer's stated target is Symfony 8.1, pre-stable, with beta packages explicitly permitted. If our applications run a supported LTS/stable minor, this bundle may simply not install without --with-all-dependencies gymnastics or a dev- alias.
• survos/kit-bundle transitive pull. We inherit that bundle's health, config surface, and any global side effects it registers. That is an unassessed dependency we did not choose.
• Asset pipeline coupling. AssetMapper/importmap is a hard architectural choice. If any target app uses Encore/Webpack, this bundle's asset registration does not apply cleanly.
• Global registrations from SurvosFwBundle.php. Compiler passes, Twig path prepends, translation domains, and asset-map entries are all things that can silently override our own templates or asset names.

Technical risk.

• Zero field evidence. 0 stars, 0 dependents, one release ("initial version"), no changelog, no consumer documentation. The only markdown in the repo is contributor guidance (AGENTS.md) aimed at maintainers of this bundle, not at teams consuming it.
• Pre-stable framework tracking. A bundle that deliberately permits Symfony beta constraints will change its own constraints repeatedly. That is churn we inherit on every composer update.
• Framework7 event semantics are the fragile seam. docs/events.md exists specifically because F7 v9's page/tab lifecycle events are DOM events plus an internal pub/sub, and the notes record that earlier listener wiring was wrong. That is a documented past breakage in the exact layer we would build screens on.
• Opinionated defaults are indistinguishable from undocumented behaviour. "Presets that reduce setup boilerplate" is a benefit inside the ecosystem and a liability outside it, because we cannot see what the preset decided on our behalf.
• Bus factor of one. Survos is a small, personal/small-team ecosystem. There is no support channel and no issue history to calibrate against.

Key questions.

1. Do any of our target applications actually run Symfony with a Framework7 mobile front end, or is this capability hypothetical?
2. Are we already consuming survos/kit-bundle? If yes, this is incremental and cheap. If no, we are adopting an ecosystem, not a package.
3. What are the exact symfony/* and PHP constraints in composer.json, and does the bundle install against our supported Symfony version without beta tolerances?
4. Does SurvosFwBundle register global Twig paths, routes, translation domains, or asset-map entries we cannot disable?
5. Which Framework7 version and build (bundle vs. ESM) does assets/package.json / importmap expect, and does it match what we would ship?
6. What is our fallback if the maintainer stops shipping — fork into the monorepo, or reimplement the ~a few hundred lines of glue?
7. If the true answer to (1) is "we could use this from Laravel," then the answer is no: the PHP side is not portable and only the JS/Twig patterns are, which we would rewrite regardless.

Integration Approach

Stack fit. Symfony + AssetMapper + Stimulus + Twig + Framework7. There is no Laravel integration path and none should be attempted; the bundle's PHP surface (AbstractUxBundle-style extension, compiler pass) is Symfony-specific. If the requirement is genuinely Laravel-side, this package is out of scope and the correct output is a "no" with the F7 patterns noted as prior art.

Migration path. There is no incumbent implementation named, so the inbound migration is greenfield. The reverse question is the important one: if we already have a working F7 mobile front end with our own Stimulus controllers and importmap entries, adopting this bundle means replacing our page/tab lifecycle wiring with theirs, including their event semantics. That is a regression-risk refactor, not an additive one. Keep our existing controller in place and put theirs behind a flag for one release cycle so screens can be reverted individually.

Compatibility — verify all of these, not just the first.

• Symfony minor against our supported matrix, resolved without minimum-stability: dev leaking into our root composer.json.
• survos/kit-bundle version alignment and its own Symfony constraint.
• Framework7 major/version parity between the bundle's importmap metadata and whatever we ship to devices — this is the check most likely to fail, given the documented v9 event change.
• Symfony UX/Twig minor versions for the component conventions in templates/components/.
• Whether the bundle's public/ CSS is intended to be served through AssetMapper versioning or copied verbatim; getting this wrong produces stale-asset incidents on mobile clients that cache aggressively.

Sequencing.

1. Spike in a throwaway Symfony skeleton with AssetMapper — install the bundle at its exact tag, register it, dump the asset map (bin/console debug:asset-map), and confirm the importmap entries and Twig namespace land where expected.
2. Read src/SurvosFwBundle.php end to end, including the compiler pass, and catalogue every global registration: Twig paths, translations, asset entries, routes, service decorators.
3. Build one non-critical screen (a list + a detail page with a tab transition) and verify behaviour against docs/events.md on a real mobile browser, not a desktop viewport.
4. Run vendor/bin/phpstan analyse and bin/console lint:twig templates/ in our own app with the bundle installed but unused, to catch boot-time conflicts before we depend on it.
5. Decide fork-versus-depend. Given the small surface and the ecosystem coupling, vendoring into the monorepo is a realistic primary option, not a fallback — the PHP glue is small, and owning it removes the constraint-churn problem entirely at a modest cost.

Operational Impact

Maintenance. The steady-state cost is higher than the package's size suggests, because we are tracking an ecosystem (this bundle plus kit-bundle) that is deliberately moving with pre-stable Symfony. Concretely: pin the exact tag rather than a caret range, because a "1.0.x" bump from a single maintainer tracking betas is not a signal of stability; re-validate constraints at each Symfony upgrade rather than discovering them at failure time; and record the symfony/* and survos/kit-bundle pins in our dependency register as known upgrade blockers.

Support. Assume none. There is no consumer documentation, no release notes beyond "initial version," no issue history, and 0 dependents — so there is no community to search when something breaks. The only in-repo documentation is maintainer-facing (AGENTS.md, docs/events.md). Our fallback must be decided before adoption: for this package, forking is the answer, and it should be budgeted as such. A critical-path dependency (mobile navigation is critical-path for a mobile app) on an unsupported first release is not acceptable without that fork already scoped.

Scaling. PHP-side overhead is negligible — a compiler pass, a service definition, Twig path registration. The real profile is front-end: Framework7 bundle size and importmap graph delivered to mobile clients, public/ CSS, and AssetMapper versioning/cache-busting behaviour. Check total transferred JS on a cold cache over a mobile network, and confirm that AssetMapper versioning actually invalidates when the bundle's assets change — a mobile client caching a stale controller is a support-ticket generator that looks like a server bug.

Failure modes.

• Constraint churn. Bundle moves to the next Symfony beta and drops the previous minor; our app cannot upgrade or cannot stay current. Mitigated only by forking or by pinning and accepting staleness.
• Framework7 event breakage. The documented F7 v9 event-name change is a preview of the next one. Any of our screens relying on lifecycle events breaks silently — no exception, just a page that doesn't transition. Mitigate with an explicit smoke test per screen type in CI against the pinned F7 version.
• Silent Twig override. Bundle-prepended template paths shadow ours; pages render "correctly" but with the bundle's markup. Detect by asserting on rendered output in a test, not by eyeballing.
• Kit-bundle drift. A change in survos/kit-bundle breaks this bundle without a release here. Pin both together.
• Asset pipeline collision. Duplicate or conflicting importmap entries cause a controller to load twice or not at all.
• Abandonment. Single maintainer, no releases since 2025-03-08, no dependents to notice on our behalf.

Ramp-up. There is no getting-started path. The realistic onboarding cost for a senior Symfony developer is 1–2 days of source reading before the first productive screen: src/SurvosFwBundle.php, then assets/package.json, then assets/src/controllers/mobile_controller.js, then the demo's app_controller.js (the de facto tutorial, since it subclasses the bundle controller), then docs/events.md. A developer without prior AssetMapper/importmap and Framework7 exposure should double that. Budget the reading time explicitly; treating this as a "just Composer require it" dependency is how the first sprint gets lost.