- Does mukadi/doctrine-crud work with Laravel?
- It can be installed via Composer alongside a Laravel app, but the package does not ship a Laravel service provider, facade, publishable config, or route registration. The evidence suggests a Symfony-first heritage, so treat the Laravel framing as unverified until you read the source. It is only realistic in a Laravel project that has already committed to Doctrine via laravel-doctrine/orm.
- How do I install mukadi/doctrine-crud?
- Install it with Composer as mukadi/doctrine-crud, but expect to write your own glue code. There is no documented Laravel integration path, no config to publish, and no service provider to register. Most teams should fork the repository, pin to a specific commit, and vendor it as a VCS or path repository rather than tracking dev-main.
- Does mukadi/doctrine-crud work with Eloquent models?
- No. It is built for Doctrine ORM managed entities, and Doctrine uses a Data Mapper pattern rather than Eloquent's Active Record approach. If you are on a standard Eloquent Laravel app, adopting Doctrine just to use this helper costs far more than writing resource controllers or using Filament, Nova, or Backpack.
- Is mukadi/doctrine-crud safe against mass assignment?
- This is the sharpest unknown and must be verified in source before any commitment. A simple CRUD helper that writes request payloads directly onto entities is a security liability unless every field is gated explicitly. If you adopt it, put an adapter layer between the helper and Laravel's request, validation, auth, and middleware stack.
- Does mukadi/doctrine-crud support Doctrine ORM 3 and modern PHP versions?
- There is no published compatibility matrix, no CI signal, and the README does not state supported doctrine/orm or PHP ranges. Doctrine ORM 2.x to 3.x is a breaking change, so confirm constraints against your composer.lock before anything else. Assume you own compatibility testing yourself.
- Is mukadi/doctrine-crud actively maintained?
- The project shows signs of being a single-maintainer package with a very small dependent base and limited downstream validation. Check the last commit date and issue responsiveness directly, and plan for the possibility that it is parked. The review burden shifts from evaluating the package to auditing and adopting it.
- Does mukadi/doctrine-crud depend on Symfony's HTTP kernel?
- The mukadi namespace, the author's Symfony bundle publishing history, and the absence of any Laravel integration point all point to Symfony origins. Whether the helper assumes Symfony Request and Response objects is the single question that decides if integration is a one-day adapter or a rewrite. Answer it by reading src/ end to end before scheduling work.
- Does mukadi/doctrine-crud generate controllers and forms?
- Documentation is limited to a README, so the source is the specification. It is unclear whether the helper produces controller actions, forms, or only persistence operations, and that scope directly determines your integration effort. Produce a one-page API surface map during a non-production spike.
- Is there a test suite or CI matrix for mukadi/doctrine-crud?
- No test suite, CI matrix, or coverage is advertised in the documentation. If you fork it, add characterization tests covering create, read, update, delete, and failure paths on every entity you expose. Those tests become your safety net for future Doctrine upgrades.
- What are the alternatives to mukadi/doctrine-crud in Laravel?
- For Eloquent apps, resource controllers, Filament, Nova, Backpack, or API Platform cover the same ground with active maintenance. For teams already running Doctrine in Laravel, laravel-doctrine/orm plus a small hand-written service layer is usually cheaper than adopting an unmaintained helper. Reserve this package for internal tooling such as admin screens and backfill utilities.