Erp Task Bundle Laravel Package

Getting Started

gepur-it/erp-task-bundle is a Symfony bundle, not a Laravel package. That distinction still drives everything: it ships a DependencyInjection/ extension, Doctrine entity mappings, Twig-facing controllers, and Resources/config/*.yaml — none of which Laravel auto-discovers. With 1 star, 0 dependents, and a repo that went quiet after 2021-04-12 until v7.0.0, treat it as a reference implementation or vendored starting point, not a dependency you can composer require into a modern Laravel app.

What v7.0.0 ("update to php 8 and fixed tests") changes for evaluation:

• The PHP floor has moved. A 2021 bundle typically pinned php: ^7.4 || ^8.0; v7.0.0 almost certainly requires ^8.0 (or ^8.1). That is the good news — PHP 8.1/8.2/8.3 no longer trips the platform check on PHP alone.
• It does not announce a Symfony major bump. The symfony/* constraints may still be 4.4/5.x, which is what actually conflicts with Laravel 10/11 (symfony/console ^6, symfony/http-foundation ^6). PHP 8 support ≠ Symfony 6 support. Verify before assuming a Laravel 11 install will resolve.
• "Fixed tests" means a working suite now exists (or was repaired). That is a real upgrade to the fork story below — but one revived release is not a maintenance commitment.

Minimal evaluation steps:

1. Read composer.json first. Confirm the new php constraint and, critically, whether symfony/framework-bundle moved to ^6 or stayed on ^4.4 || ^5.0. If it stayed, Laravel 10/11 composer require still fails and that's the reason, not your environment. If it moved to ^6, Pattern A below becomes viable in a modern Symfony host — a genuine change from the previous assessment.
2. Inspect in this order: README.md → DependencyInjection/*Extension.php (what services/config the bundle registers) → Resources/config/routing.yaml and services.yaml → Entity/ (the actual domain model) → Controller/ → tests/ (new/updated in v7.0.0). The entities remain the most portable artifact.
3. Identify the host integration path. Either (a) you actually have a Symfony host in your stack, or (b) you are porting the task model into Eloquent. Do not attempt (c) run a Symfony bundle inside Laravel via a bridge — the bundle's DI, routing, and Twig assumptions make this a multi-day trap.

First use case: an internal ERP backoffice task board — create/list/assign tasks, track status and priority, link tasks to ERP records (orders, customers, invoices). Clone the entity shape and route structure, then rebuild it natively in Laravel. That is the fastest path to day-one value.

Implementation Patterns

Pattern A — Evaluate/run inside a Symfony host (now more plausible).

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

# config/routes.yaml
erp_task:
    resource: '@ErpTaskBundle/Resources/config/routing.yaml'

Then bin/console debug:container --tag=... and bin/console debug:router to confirm what the extension actually registered. Run doctrine:schema:validate before any migration — bundles of this vintage often assume existing tables. On PHP 8.2+ watch for dynamic-property and ${var} string-interpolation deprecations in the bundle source; v7.0.0 claims PHP 8 support, so run the bundled test suite on your target PHP version to confirm it actually holds.

Pattern B — Port the domain model to Laravel (the realistic path).

Map the Symfony artifacts directly:

// database/migrations/xxxx_create_tasks_table.php
Schema::create('tasks', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->text('description')->nullable();
    $table->string('status')->default('open');   // mirror bundle's status enum
    $table->string('priority')->default('normal');
    $table->foreignId('assignee_id')->nullable()->constrained('users');
    $table->nullableMorphs('taskable');          // link to orders/customers
    $table->timestamps();
});

// app/Providers/TaskServiceProvider.php
public function register(): void
{
    $this->app->bind(TaskManager::class, fn ($app) =>
        new TaskManager($app->make(TaskRepository::class))
    );
}

Pattern C — Workflow/state integration. Keep status transitions explicit rather than free-form strings. The bundle likely encodes a status list; lift it into an enum or a small state machine and gate transitions in a policy. v7.0.0 adds no new domain concepts, so whatever you lifted from the pre-7 model still holds.

enum TaskStatus: string { case Open = 'open'; case InProgress = 'in_progress'; case Done = 'done'; }

Integration tips: keep assignment and priority as config-backed enums so the bundle's vocabulary survives the port; wrap task creation in a service class (TaskManager) so controllers stay thin and the logic is unit-testable independent of HTTP.

Gotchas and Tips

• One revive is not maintenance. v7.0.0 is the first release since 2021-04-12, and it is a PHP-baseline housekeeping release, not a feature release. Still 1 star, 0 dependents, MIT. Do not put it on a production critical path un-forked; do not read one modernized tag as "actively maintained."
• PHP 8 support may not mean Symfony 6 support. Re-check the symfony/* constraints specifically. If they remain 4.4/5.x, Laravel 10/11 composer require still fails. Resolve by forking into a private packages/ repo or copying the entity code — never with --ignore-platform-reqs.
• No Laravel auto-discovery. There is no extra.laravel.providers — you will get a "class not found / not booting" surprise if you assume the package registers itself. This is unchanged by v7.0.0.
• Doctrine vs Eloquent impedance. Entity annotations/attributes, EntityManager, lazy proxies, and flush() have no Eloquent equivalents. Budget real time for this; the port is mechanical but not trivial.
• Schema assumptions. Migrations may be missing entirely. Grep Resources/ and Migrations/ for table names; verify against a clean DB before running anything against shared data.
• Bundle registration is manual. In Symfony it must appear in config/bundles.php; missing entry means services silently don't exist → "service not found" at resolve time, not boot time.
• Tests now exist — use them. "Fixed tests" in the release notes means the suite is your cheapest verification of the new PHP 8 baseline. Before you fork, run the suite on your target PHP/Symfony versions. Before you refactor a port, write characterization tests around the entity/service layer first — that's your safety net.
• Debugging shortcuts. bin/console debug:container <id>, debug:router, debug:event-dispatcher. For the Laravel port, log transitions in TaskManager — most bugs are state-machine bugs, not persistence bugs.
• Extension points to reuse. If you fork, DependencyInjection compiler passes and event subscribers are the cleanest hooks for customizing behavior without editing the bundle source.
• Security review. Low release cadence and no dependents mean no external scrutiny. Do a quick manual review of controller input handling and mass-assignment paths before exposing routes.
• Pin and document. If you fork: pin a commit (ideally the v7.0.0 tag, so you inherit the PHP 8 fixes), keep the MIT license header, and record the upstream URL, tag, and diff in your README so a future maintainer knows what was inherited.