Generic Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/CRUD scaffolding: The new CRUD route-generation traits let a small team stand up standard create/read/update/delete endpoints without hand-writing boilerplate — a direct lever on whether we staff a platform squad or lean on a package. Worth modelling in a spike before committing headcount to internal tooling.
• Feature scope for internal tooling and admin surfaces: DateRange/DateRangeType and the highlight Twig filters are exactly the kind of small, user-visible conveniences (date filtering on reports, search-term highlighting) that otherwise become ticket-by-ticket work. We can pull these forward into the roadmap for admin/reporting features rather than scheduling them as bespoke builds.
• Test and QA strategy: MockAuthenticatorFactory/MockAuthenticator reduce the cost of writing auth-related tests and demos. That is a velocity decision, not just an engineering nicety — it lowers the barrier to covering protected paths in CI.
• API contract and error-shape decisions: The form_error_with_errors context for FormErrorNormalizer affects what our validation error payloads look like to clients. If we expose form validation to a frontend or third party, this is an API design decision worth locking in deliberately.
• Serialization artifact management: SerializerDumpCommand (YAML dump) enables treating serialization config as a reviewable, diffable artifact — supports our auditability/compliance story and eases schema-change reviews.
• Platform currency: The PHP 8.2 / Symfony 7.4 floor is a roadmap input. It sets a minimum runtime for anything adopting this package and should be reconciled with our broader upgrade calendar before we commit.
• Deprecation/rename tracking: The knp_current_page_number → knp_current_page and currentPageNumber → currentPage renames, the removed JsonResponseListener::onKernelResponseForNoContent(), and Nestable becoming abstract are all things that will surface as breakage in templates and downstream code. Budget migration effort accordingly if we have existing consumers.

When to Consider This Package

Adopt when: we are building a server-rendered Symfony-style PHP application with form-heavy admin screens and paginated lists; we want CRUD scaffolds, pagination decoration, form-error normalization, and test doubles without writing them ourselves; the team is already on PHP 8.2+ and can move to Symfony 7.4; and we value a YAML-serialized, reviewable configuration artifact.

Look elsewhere when: our stack is Laravel-first — despite being a PHP package, this release is explicitly Symfony-centric (Twig filters, KnpPaginator decoration, Symfony 7.4 minimum, form-error normalization tied to Symfony forms). Forcing it into a Laravel product means fighting the framework boundary and owning adapters. Also look elsewhere if we cannot absorb breaking renames and a removed listener on short notice, if we are pinned below PHP 8.2 for hosting or client-environment reasons, or if we need a stable long-term-support line rather than a rapidly iterating package.

Adoption criteria to confirm before committing: an owner for the PHP 8.2/Symfony 7.4 floor in our upgrade plan; a written inventory of any existing usage of the renamed pagination variables and the removed no-content listener; and a decision on whether Nestable subclassing (now abstract) affects us.

How to Pitch It (Stakeholders)

To executives: This release adds ready-made building blocks for admin screens and internal tools — CRUD route generation, date-range filtering, highlighting, test helpers, and configuration export for audit review. Practically, it shifts work from custom development to configuration, which compresses delivery time and cost on back-office features. The trade-off is a raised platform floor (PHP 8.2, Symfony 7.4) and a set of renames/removals that require a small, bounded migration. It is a low-risk, moderate-upside adoption if our stack aligns with Symfony-style PHP; it is not a fit for a Laravel-centered product.

To engineering: v1.2.0 is largely additive — CRUD traits, SerializerDumpCommand, DecoratingKnpPaginator, auth mocks, DateRange/DateRangeType, highlight filters, and richer form-error context. The breaking surface is explicitly enumerated: two pagination identifier renames, removal of JsonResponseListener::onKernelResponseForNoContent(), and Nestable becoming abstract. Please produce a short impact assessment against our codebase and template layer, and validate the PHP 8.2/Symfony 7.4 requirement against our deployment targets. Recommended next step: a timeboxed spike on the CRUD traits and paginator decorator in a non-critical service to confirm the abstraction holds up.

Recommendation: Adopt on a trial basis contingent on stack alignment and the migration inventory above; otherwise deprioritize in favour of framework-native tooling.