- Is huluti/doctrine-relations-analyser a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a native Laravel package. It analyses Doctrine ORM entity metadata, so in Laravel it only fits apps using laravel-doctrine or Doctrine ORM as the mapper. Eloquent-only projects do not expose an equivalent metadata graph for it to inspect.
- How do I install huluti/doctrine-relations-analyser in a Laravel application?
- Install it with composer require --dev huluti/doctrine-relations-analyser and register the bundle manually in config/bundles.php for dev and test environments. There is no Symfony Flex recipe, and doctrine/dbal alone is not enough because the tool needs full ORM entity metadata. Budget a short spike to confirm the console command loads in your kernel.
- Does it work with Laravel Eloquent models?
- No. Eloquent does not expose Doctrine-style owning and inverse side or cascade metadata, so the analyser has nothing to read. For Eloquent you would need a bespoke Artisan command over model reflection or Model::resolveRelationUsing. Use this package as a pattern reference for relation-hygiene checks instead.
- Which Doctrine ORM and Symfony versions does it support?
- Verify the bundle's version constraints against your PHP floor, Symfony version, and Doctrine ORM major version before merging. Doctrine ORM 2.x to 3.x changed attribute mapping and metadata APIs, so confirm ORM 3 and PHP attributes support if you depend on them. Bundle registration failures often surface as command not found, which is easy to misdiagnose.
- What kinds of Doctrine relationship problems does it detect?
- It reports on association hygiene such as bidirectional completeness, owning and inverse sides, cascade configuration, and orphan removal. The analysis is static and heuristic, so expect false positives for intentional unidirectional relations and false negatives around inheritance or trait-composed mappings. Treat findings as review input rather than absolute truth.
- Does it require a live database connection to run?
- The core analysis works from Doctrine mapping metadata, so it should not need a live database for relation inspection. Confirm this during your pilot, because Doctrine console tooling sometimes boots the full kernel and entity manager. If it does boot the EM, point it at a disposable dev database.
- Can I use the output in CI as a blocking check?
- Start in report-only mode and capture a baseline of current findings before gating anything. The output is typically a human-readable console report, so confirm whether a machine-parsable format exists before adding blocking CI logic. A practical path is a non-blocking informational job first, then blocking only on new or changed entities.
- Does it handle inheritance, embeddables, and mappings spread across bundles?
- Coverage depends on how your Doctrine metadata driver resolves mappings, so test against your real entity graph. Inheritance hierarchies, embeddables, trait-composed mappings, and multi-bundle mapping config are common sources of missed or misread relations. Record findings as known issues rather than remediating legacy mappings upfront.
- Is it safe to install in a production Laravel app?
- It is a dev-time analysis tool, so installing it as require-dev with dev and test bundle registration keeps it out of production runtime paths. It does not change schema or data, which keeps the blast radius small. Do not adopt it as a runtime dependency in Eloquent-based services.
- What are the maintenance risks and what should I use instead?
- Adoption is low, around 15 stars and no dependents, so there is little downstream validation. Mitigating factors are the MIT license, a small self-contained codebase, and dev-only scope, which make it cheap to fork, vendor, or replace. For Eloquent estates, use the relation-hygiene dimensions it checks as review checklist items instead.