Core Bundle Laravel Package

Technical Evaluation

Stack correction (blocking). Despite the brief describing this as a "Laravel/PHP package," whatwedo/core-bundle is a Symfony bundle. The *Bundle suffix, the whatwedo namespace, and the nature of the package all point to Symfony's bundle/DI-extension model, not Laravel service providers. There is no Laravel integration path, no facade, no config-publishing convention. If the target platform is Laravel, this is a hard disqualify and should be closed at triage rather than carried into evaluation. Everything below assumes a Symfony target or a decision to re-scope.

Architecture fit. This is not a product feature — it is a shared base layer. The description ("reusable components used by other bundles of whatwedo") tells you the actual unit of evaluation is the whatwedo bundle family (table, CRUD, search, user-adjacent bundles), not this repository. CoreBundle has near-zero standalone value; it exists so sibling bundles don't duplicate base entities, traits, and service wiring. That has two consequences:

• Its public API is incidental, not contractual. Whatever the sibling bundles happen to need becomes the surface area. Expect to subclass base classes, override services, and conform to their conventions rather than compose with them.
• You cannot adopt it à la carte. Adopting it means adopting, or at minimum tracking, the family's release and upgrade schedule.

Integration feasibility. Technically trivial: Composer-installable, MIT-licensed, standard Symfony bundle registration. The cost is not installation; it is the inheritance coupling that follows. Base-class extension is the intended integration mechanism, which means the framework's internals become part of your application's shape over time.

Technical risk — this is the dominant concern. 6 stars and 0 Packagist dependents means:

• No external bug reporters. Edge cases in your stack are almost certainly untested.
• No third-party consumers to absorb upgrade breakage before you do.
• No observable security-disclosure process; you are reliant on the maintainer noticing and publishing.
• Bus factor concentrated in a single agency. If the agency's priorities move, the bundle is frozen in place.
• Semver discipline is unverified. "Core" bundles frequently version-lock their siblings, which converts a routine Symfony major upgrade into a coordinated, multi-bundle, single-vendor-timetable migration.

Key questions for the maintainer / spike:

1. Which sibling bundles does our use case actually require, and what is their combined dependency graph?
2. What are the declared PHP, symfony/*, and doctrine/* constraints, and how recently were they bumped?
3. What is the release cadence over the last 24 months, and what is the support window past Symfony EOL?
4. Is there any commitment to API stability across minor versions?
5. Can we obtain a fork-and-patch right, and is there a documented upgrade guide between majors?
6. Who is the named internal owner, and what is the exit cost if upstream is abandoned?

Integration Approach

Stack fit. Symfony + Doctrine only. If the organization standardizes on Symfony 6/7 with Doctrine ORM, the bundle is at least reachable. If it is Laravel, or Symfony without Doctrine, stop.

Migration path. Do not greenfield on a 6-star core bundle. Three viable stances, in order of preference:

1. Pattern reference only — read the base entities and traits, reimplement the small useful subset internally. Captures the ideas, keeps zero dependency risk. Best default.
2. Scoped adoption — use it only where a required sibling bundle already forces it, with a pinned minor version and a facade layer in front.
3. Full family adoption — only defensible if the sibling bundles deliver substantial out-of-the-box functionality (CRUD scaffolding, table rendering) that would cost more to build than to inherit the coupling.

Compatibility work before commitment. Read composer.json constraints directly against the target Symfony version and the current support matrix. Confirm the last release date post-dates the Symfony version you plan to run. Run composer why-not against the intended stack to expose transitive pinning conflicts — a classic core-bundle failure signature — before writing any application code.

Sequencing.

1. Resolve the Laravel-vs-Symfony question and record the decision.
2. Inventory the sibling bundles and their combined dependency graph; confirm CoreBundle is load-bearing for at least one of them.
3. Spike in a throwaway Symfony app: install, extend one base class, run the actual code path, measure. Timebox it.
4. Decide stance (reference / scoped / full).
5. If scoped or full: mirror the repository, tag a known-good commit, and write the fork policy before the first production commit.
6. Introduce a thin internal adapter over the bundle's base classes so an exit is a bounded change rather than a rewrite.
7. Legal/licensing sign-off on MIT (trivial, but confirm attribution and any bundled third-party notices).

Operational Impact

Maintenance. You inherit the vendor's cadence, not your own. Budget an explicit line item for fork maintenance and periodic upstream diffing — a mirrored repo plus a release-watch routine. If that line item cannot be staffed, downgrade to the pattern-reference stance.

Support. No documented commercial SLA. Support is GitHub issues at best. There is no CVE feed with this package's name on it, so security response is inbound from your own monitoring — subscribe to Symfony security advisories and treat CoreBundle as untracked transitive risk.

Scaling. Performance is unproven at this adoption level; assume nothing. Core bundles commonly introduce query overhead through base repositories and CRUD conventions that look fine at hundreds of rows and degrade at millions. Load-test the specific paths you exercise, not the bundle in aggregate, and inspect generated SQL for the list/index paths in particular.

Failure modes to plan for:

• Composer constraint deadlock. CoreBundle pins a package version that a newer dependency needs. Mitigation: pinned versions, composer why-not in CI, and a fork ready.
• Silent minor-version breakage from an unpublished BC break in what is effectively an internal API.
• Inheritance lock-in. Six months of subclasses makes replacement a refactor project. Mitigation: the adapter layer, established early.
• Upstream abandonment leaving you on an EOL Symfony with no upgrade path. Mitigation: fork rights, mirrored repo, documented exit plan.
• Convention mismatch. Engineers apply generic Symfony idioms and fight whatwedo's opinions, burning time in code review.

Ramp-up. Non-trivial relative to the bundle's apparent size, because the learning is whatwedo's conventions, not Symfony. Assume 1–2 weeks for a mid-level Symfony developer to be productive within the bundle's idioms, front-loaded on the CRUD/table base classes; materially less if you only touch a narrow slice. Documentation is likely thin — plan to write internal onboarding notes as a deliverable of the spike, and treat their absence as a recurring tax on every new hire who touches the code.

TPM stance. Low-adoption, vendor-coupled base layer with derivative value. Default to pattern reference; adopt only under the compulsion of a sibling bundle you genuinely need, and only with a fork policy and adapter layer in place before production.