Framework Core Bundle Laravel Package

Technical Evaluation

Architecture fit: FrameworkCoreBundle is a SumoCoders internal shared bundle that aggregates cross-project framework code (base controllers, form types, security helpers, UI scaffolding). Despite being routed through a "Laravel/PHP package" review track, it is a Symfony bundle, not a Laravel package. v19.2.0 adds a "quick search" capability (PR #260) — a UI/feature-layer addition that sits on top of existing bundle infrastructure rather than altering the extension points consumers depend on. It fits the bundle's established role as a grab-bag of reusable application concerns, but it also reinforces a known architectural smell: feature-level UI (search) shipping inside a core framework bundle couples presentation concerns to infrastructure that every consumer inherits.

Integration feasibility: Low friction. Minor version bump from 19.1.4 → 19.2.0, single PR, no deprecations, no config schema changes surfaced in the notes. For Symfony consumers already on the 19.x line, a composer update should suffice. The real cost is not the upgrade but the adoption decision: quick search is opt-in UI, so teams must decide whether to wire it in, template-override it, or ignore it.

Technical risk: Low-to-moderate.

• Low: No breaking changes indicated; patch-level risk profile for existing behaviour.
• Moderate: FrameworkCoreBundle is a single-maintainer-dominated, low-bus-factor project (PR authored by a named SumoCoders developer; changelog detail is thin — one line, no screenshots, no config docs, no tests referenced). A UI feature with no accompanying documentation in the release notes is hard to evaluate for accessibility, i18n, or search-backend expectations.
• Moderate: "Quick search" implies a search backend or at minimum a route/controller contract. If that contract is opinionated (e.g. assumes Doctrine, a specific index, or a specific JS stack), consumers on divergent stacks may get partial or broken behaviour.

Key questions:

1. Is quick search enabled by default or opt-in via config? If default-on, it is effectively a behavioural change disguised as a feature.
2. What are its dependencies — Doctrine ORM, a search engine, a specific frontend asset pipeline (Webpack Encore / AssetMapper)?
3. Does it introduce new routes, and are those routes secured by default?
4. Is the search parameterised/safe against injection, and does it respect existing access-control voters?
5. Are there tests and docs, or is PR #260 the entirety of the specification?
6. What is the support window for 19.x, and is 19.2.0 a drop-in for apps still on 18.x?

Integration Approach

Stack fit: Only relevant if the consuming application is Symfony (5.4/6.x/7.x depending on the 19.x support matrix) — not Laravel. Any Laravel service in the portfolio should be excluded from this rollout entirely. For Symfony apps, fit depends on whether the bundle is already a dependency; if it is, this is a routine bump.

Migration path: Straightforward for existing 19.x consumers:

1. composer require sumocoders/framework-core-bundle:^19.2 in a non-production branch.
2. Run the test suite and a smoke pass on any screens using bundle-provided templates or layouts, since quick search may inject markup into shared base templates.
3. Diff published assets/templates (bin/console assets:install, template override check) to catch silent UI changes.
4. Promote through staging before production.

For apps on 18.x or earlier, this is not the upgrade to plan around — batch it with the existing major-version migration rather than treating 19.2.0 as the driver.

Compatibility: Verify PHP version constraints and Symfony component ranges in composer.json before committing. Because the changelog omits dependency changes, treat composer why-not output as the source of truth. Check for conflicts if the app pins its own search/UI packages.

Sequencing:

1. Confirm Symfony (not Laravel) and 19.x eligibility — gate.
2. Read PR #260 diff and any linked issues to understand opt-in mechanics — gate.
3. Bump in a low-traffic service first (canary), not a customer-facing flagship.
4. Only after canary stability, evaluate adopting quick search as a feature; adoption is a separate, later decision from the version bump.
5. Defer fleet-wide rollout until docs exist or an internal README captures the contract.

Operational Impact

Maintenance: Near-zero incremental maintenance for the bump itself. The feature adds surface area to a bundle the organisation does not own — every consumer now carries code whose roadmap is set externally by SumoCoders. Ongoing cost is monitoring upstream releases for breaking changes at major bumps, plus internal template overrides if quick search's default markup conflicts with design systems.

Support: Support path is upstream GitHub issues plus internal expertise. Given a one-line changelog, internal support burden will fall on whichever engineer reads the diff. Budget a small spike (half a day) to document the feature internally before wide adoption; otherwise each team re-derives the same knowledge.

Scaling: The version bump scales trivially. The feature does not automatically: quick search behaviour under large datasets, many concurrent users, or non-indexed queries is unproven from the notes. If teams enable it broadly, watch query latency and database load, particularly if it performs LIKE-style scans against primary tables. Treat search as a capacity-sensitive path and load-test before enabling on high-traffic properties.

Failure modes:

• Silent UI regression: quick search markup leaking into shared base templates and disturbing layouts in apps that never opted in.
• Default-on surprise: search enabled without explicit config, exposing an unintended endpoint or query load.
• Autoload/asset drift: published assets not refreshed, producing broken front-end behaviour that looks like an app bug.
• Dependency conflict: new transitive requirement clashing with app-pinned packages, surfacing at deploy rather than at composer update.
• Knowledge gap: no docs means no one can debug the feature during an incident.
• Major-version cliff: staying on 19.x indefinitely while upstream moves to 20.x, accumulating debt.

Ramp-up: Low for the version bump — a mid-level engineer can execute the upgrade in under a day per application. Moderate for feature adoption — requires familiarity with the bundle's templating and routing conventions plus the search backend it assumes. Recommended: one engineer owns the canary upgrade and writes a short internal note covering opt-in mechanics, routes added, and rollback steps; that note becomes the ramp-up artifact for the rest of the fleet.