- Does lephare/import-bundle work with Laravel out of the box?
- No. le-phare/import-bundle is a Symfony bundle, not a Laravel package: it registers services through a DependencyInjection extension and compiler passes, ships YAML/XML config trees, and tags console commands with console.command. Laravel has no bundle system, so there is no facade, no config/import.php publish hook, and no laravel/framework version constraint in evidence. Adopting it means writing and owning an adapter layer rather than just running composer require.
- How do I install lephare/import-bundle in a Laravel application?
- You can composer require it, but package discovery will not wire anything into Laravel's container. You must either re-declare each service, alias, and parameter inside a service provider, or stand up symfony/dependency-injection standalone and bridge it. The lower-risk middle path is to skip the bundle's console wiring entirely and construct only the importer classes you actually need.
- Can I run the importer inside a Laravel queued job instead of the Symfony console command?
- Yes, and that is the recommended shape. Ignore the console command, bind the underlying importer service in a provider, and call it from a job behind a ShouldQueue boundary so bulk imports run off the request cycle. This turns the work from porting a bundle into binding two or three classes, and it keeps the part most entangled with Symfony's container lifecycle out of your bootstrap.
- What does lephare/import-bundle depend on: Doctrine ORM, Doctrine DBAL, or plain PDO?
- That is not documented in the material under review, and it is a question you must answer before committing. Doctrine ORM or DBAL would pull entity and connection assumptions into your adapter, while plain PDO keeps the integration surface small. If the importer assumes Doctrine entities, integration cost rises substantially, so confirm the hard dependencies in a timeboxed spike first.
- Why would php artisan config:cache or package:discover fail with a database connection error?
- Artisan instantiates and registers commands during framework bootstrap, so a command whose constructor injects a database-dependent service will open a connection during config:cache, route:cache, or package:discover in CI. That is the same defect class behind the Symfony fix in v2.2.5, where ImportCommand was eagerly instantiated and forced a connection during cache clear (#52). The upstream patch does not protect your wiring, so verify your own provider is lazy and never resolves the importer at boot.
- Does Laravel auto-register the bundle's ImportCommand in artisan?
- No. Laravel registers commands through Kernel::commands(), auto-discovery under app/Console/Commands, or a package's service provider. A Symfony console.command tag means nothing to Laravel, so the bundle's ImportCommand will not appear in artisan list unless you explicitly register or wrap it. Leaving it unregistered is usually the safer choice.
- Should I pin an exact version of lephare/import-bundle?
- Yes. v2.2.5 shipped an add-then-partially-reverted fix inside a single patch (#52 and #53), which suggests the laziness boundary is still being tuned upstream. Pin exact versions rather than floating on ^2.2, and re-test your adapter whenever you bump. The patch itself is non-breaking with no API change or migration, so pinning costs you nothing.
- How should I test a CSV import integration in a Laravel app?
- Test the importer service directly rather than through artisan. Use an in-memory SQLite connection, a small fixture CSV that covers malformed rows and validation failures, and assert on the resulting rows plus the error and progress reporting. Keeping the Symfony kernel out of the test path makes the suite fast and pins the exact surface your adapter depends on.
- Is there a framework-agnostic core I can bind without symfony/dependency-injection?
- That is the key spike question. If the importer can be constructed without symfony/dependency-injection, you can bind it straight into Laravel's container and the integration stays cheap. If it cannot, stop and escalate, because you would then be maintaining a container bridge rather than a thin adapter.
- What should I ask the maintainers before adopting this package, and what are the alternatives?
- Ask whether Laravel is supported at all or the package is Symfony-only by intent, whether a framework-agnostic core exists, what the hard dependencies are, and the PHP and Symfony version floors. Also ask whether the importer is idempotent and chunkable or assumes a full in-memory dataset, and whether #52 was a lazy proxy fix or a constructor-signature change. If the answers are unfavorable, evaluate Laravel-native import packages instead of porting a bundle.