Cruditplatform Bundle Laravel Package

Product Decisions This Supports

Bottom line up front: this package should not be evaluated as a Laravel package. Despite the "Laravel/PHP" framing, 2lenet/cruditplatform-bundle is a Symfony bundle and a thin companion to 2le/crudit (the Symfony CRUD/admin generator). Its releases are almost entirely about one narrow concern — "credential warmup" (bootstrapping role/permission definitions at platform warmup time) plus Symfony Flex/compatibility housekeeping. That scope determines every decision it can support.

• Ecosystem decision (the real one): "Do we standardize on 2le/crudit for admin/back-office tooling?" This package is a downstream artifact of that decision, not an independent choice. If the answer is no, this package is out of scope immediately.
• Build vs. buy for internal admin/back-office surfaces. Relevant only for Symfony teams who would otherwise hand-roll CRUD screens and role bootstrapping. Comparable Laravel-native options (Filament, Nova, Backpack) cover this ground with orders of magnitude more community, docs, and hiring pool — so a Laravel team comparing this to those is comparing the wrong column.
• Platform setup / provisioning cost. The one genuinely reusable capability is credential/role warmup: eliminating manual, per-environment role seeding and keeping role labels consistent across deploys. If we repeatedly spin up environments and hand-configure roles, that is a real (if small) operational cost worth naming.
• Roadmap and staffing signal. Adoption implies the team needs Symfony fluency, not Laravel. That is a hiring, onboarding, and on-call consequence — a product/org decision, not just a technical one.
• Risk posture decision. 1 star, 0 dependents, single-maintainer commit history, no README beyond the install line, and a major 2.0.0 version bump specifically for "credential compatibility" — i.e., breaking changes land in the authentication/authorization area. Treat as "vendor-in-source" code we own, not a dependency we consume.
• Use cases it plausibly serves: internal-only admin panels, back-office data management on an existing Symfony estate, legacy Symfony modernization, and short-lived prototypes.

When to Consider This Package

Consider it if:

• You are on Symfony (7/8) and already using, or committed to, 2le/crudit — in which case this is near-mandatory glue and the decision collapses into "keep it pinned and fork-ready."
• Role/permission bootstrap and warmup is a recurring manual chore across environments, and the bundle's credential warmup maps to your auth model.
• You accept owning the code: MIT license, permissive, small surface area, auditable in an afternoon.
• You are comfortable with zero external support — no issue triage, no Slack, no dependents to learn from.

Look elsewhere if:

• You are a Laravel shop. This is not Laravel-native. Use Filament, Laravel Nova, or Backpack — you get docs, a maintainer community, a hiring pool, and no Symfony container bridging.
• You need community support, SLAs, documentation, or a second maintainer. None exist here.
• Your authorization model is non-standard (multi-tenant, ABAC, external IdP). The package's entire value proposition is a specific role/credential warmup convention; deviating from it deletes the benefit and leaves you with the maintenance.
• You need a CRUD generator or UI. This package doesn't provide them — 2le/crudit does. Scope confusion here is the most likely way a stakeholder gets burned.
• You cannot absorb a breaking auth-adjacent upgrade on someone else's schedule.

Gate before any adoption: a time-boxed (≤1 day) spike in a throwaway Symfony app — install, run warmup, confirm role/credential behavior and version constraints via composer why-not. Do not commit roadmap capacity on the strength of the README.

How to Pitch It (Stakeholders)

For executives: Keep this small and honest — do not attach a percentage to it. "We evaluated a small MIT-licensed Symfony helper that automates role and permission setup for admin tooling. It's well-scoped but effectively a one-person project with no users, no documentation, and breaking changes in the authorization area. Our recommendation is: do not adopt. If we ever standardize our back-office tooling on the 2le/crudit stack, revisit it then — the integration cost is low and a one-day spike would confirm fit. For our Laravel work, the mature equivalents (Filament, Nova) are the right comparison." The cost of this decision is a day of evaluation; the cost of skipping the evaluation is an unmaintained auth-adjacent dependency.

For engineering: "cruditplatform-bundle is not a CRUD framework — it's a Symfony platform-glue package for 2le/crudit, and its changelog is almost entirely credential/role warmup. What it buys us: automated role bootstrapping and consistent role labels across environments. What it costs us: single maintainer, zero dependents, no tests surfaced, no docs past composer require, and a 2.0.0 major bump for 'credential compatibility' — meaning upstream can break our auth wiring on their release cadence. Recommendation: pin exactly, vendor the source, treat it as code we own. Do not adopt unless we're already on 2le/crudit; if we are, adopt it and budget an afternoon to read every line."

For design/UX: "No impact — this package ships no UI. Admin screens, forms, and templates come from 2le/crudit or from us. Flag it only because 'CRUD bundle' language in a ticket could be misread as 'we get an admin panel for free.' We don't."