Cruditplatform Bundle Laravel Package

Getting Started

First, the reality check that determines everything else: 2lenet/cruditplatform-bundle is a Symfony bundle, not a Laravel package. It has no ServiceProvider, no extra.laravel.providers auto-discovery entry, and no Blade/Twig-optional views. composer require 2lenet/cruditplatform-bundle will succeed in a Laravel app (it's just PHP + Composer), but it will do nothing — Symfony bundles are only loaded through config/bundles.php and a Symfony kernel boot.

So the honest "minimal steps" for a Laravel developer are:

1. Verify the stack fit before writing any code. Open the package's composer.json and confirm what it requires: symfony/framework-bundle, symfony/dependency-injection, and almost certainly 2le/crudit. If symfony/framework-bundle is a hard requirement, treat this as ineligible for a Laravel project and stop here.
2. Use it only in the context it was built for — a Symfony app with 2le/crudit. Registration is:

   // config/bundles.php
   return [
       // ...
       TwoLE\CruditPlatformBundle\CruditPlatformBundle::class => ['all' => true],
   ];
   

3. Look first at CruditCredentialWarmup. Based on the entire release history (1.0.2 "Create workflow credential warmup", 1.0.4 fix, 1.0.6 "Fix warmup", 2.0.0 "Modify warmup for credential compatibility"), the bundle's functional surface is essentially a cache-warmup hook that prepares crudit workflow credentials/roles at container/cache warmup time. That is your first and probably only use case: making a crudit-based admin boot cleanly after a cache clear.
4. Confirm it works with one command: bin/console cache:warmup -vvv (see Gotchas for what to look for in the output).

If you are on Laravel and need CRUD admin scaffolding day-to-day, this package is the wrong tool — see the alternatives at the end of Implementation Patterns. The rest of this assessment assumes either a Symfony app or a deliberate, isolated bridge.

Implementation Patterns

Pattern 1 — "Warmup as a deploy step" (the realistic day-to-day use). If you run a 2le/crudit-based admin, the bundle's value shows up in CI/CD and deploy scripts, not in application code:

# deploy pipeline
- run: bin/console cache:clear --no-warmup
- run: bin/console cache:warmup -vvv   # CruditCredentialWarmup runs here

The pattern that matters is warming after every credential/role change. Since 2.0.0 changed warmup "for credential compatibility", pin the bundle version in composer.json and re-run your warmup smoke test on every upgrade — this is the class of thing that silently breaks a login flow.

Pattern 2 — Treat it as a thin, replaceable warmup layer. Because the bundle is small, the safest integration is to not depend on it directly from your application code. Let it be a passive registered bundle; if you need custom behaviour, decorate the warmup service rather than editing vendor code:

# config/services.yaml
services:
    App\Crudit\MyCredentialWarmup:
        decorates: twole.crudit_platform.credential_warmup   # verify the real service id with `debug:container`
        arguments: ['@.inner']

Find the real service id with bin/console debug:container --show-private | grep -i warmup before writing the decorator — the README does not document it, so this is discovery work, not copy-paste.

Pattern 3 — Isolated bridge (Laravel app, only if you must). If someone insists on reusing the warmup logic from Laravel, do not try to boot the bundle. Extract the intent into a Laravel command and keep the Symfony bundle out of your dependency graph:

// app/Console/Commands/WarmupCredentials.php
class WarmupCredentials extends Command
{
    protected $signature = 'crudit:warmup';
    public function handle(): int { /* replicate the warmup logic against your own models */ }
}

Booting a Symfony Bundle inside Laravel requires hand-rolling an Extension/ContainerBuilder lifecycle — that is days of work to gain one warmup routine. Not worth it.

Pattern 4 — Choose the right tool for the actual job. For day-to-day Laravel CRUD scaffolding, the community-standard choices are filamentphp/filament, backpack/crud, or laravel/nova. They ship Laravel ServiceProviders, Blade views, policies, and migrations. If a stakeholder has proposed this bundle for a Laravel admin panel, the correct technical recommendation is to decline and route to one of those.

Gotchas and Tips

• Composer success ≠ installation. There is no Laravel auto-discovery. In a Laravel app the package will sit inert in vendor/ and every "it's installed but nothing happens" symptom traces back to this.
• Zero dependents, 1 star, one-line README. You are the documentation. Budget time for reading vendor/2lenet/cruditplatform-bundle/ directly — the bundle is small enough that this is minutes, not hours, but plan for it.
• The release dates are suspicious. The listed last release (2026-08-05) is a future date relative to most projects; verify the actual tag and treat version metadata as unreliable until you've inspected the tag itself.
• 2.0.0 is a breaking change on the one feature that matters. "Modify warmup for credential compatibility" means an upgrade can change how credentials are materialised during warmup. Read the diff of PR #9 before bumping, and run a login smoke test after.
• Hard coupling to 2le/crudit. If 2le/crudit isn't installed or is the wrong major, expect container compile errors, not runtime warnings. Check with composer why 2le/crudit and composer why-not 2le/crudit <version>.
• Debugging order for a broken warmup:
  1. bin/console lint:container — catches service wiring faults at compile time.
  2. bin/console cache:warmup -vvv — the bundle only executes here; a silent failure looks like a missing role/credential later.
  3. bin/console debug:container CruditCredentialWarmup — confirm the service is registered and which class backs it.
  4. Only then inspect the role labels — 1.2.0 changed "role label in warmup", so label drift is a known failure mode.
• Don't fork for small changes. Decoration (Pattern 2) covers most needs without taking on maintenance of a 1-star repo. Fork only if you must patch the warmup for a framework-version incompatibility.
• Pin the version in composer.json ("2lenet/cruditplatform-bundle": "2.0.*"), not a floating constraint. With no test suite and no community, an unattended composer update is an unmonitored production change.
• Extension point that actually exists: cache warmup runs on every deploy and cache clear — so anything you put in that warmup is effectively a deploy hook. That's the lever to use, and also the reason to keep the warmup cheap (no remote API calls, no heavy queries).
• Escalation reality: no issues community, no Slack, no tests. Open issues with reproduction steps in the repo, but assume you will debug locally.