- Is ibrows/import-bundle a Laravel package?
- No. ibrows/import-bundle is a Symfony bundle built around Symfony kernel registration, DI compiler passes, YAML service configuration, and Doctrine ORM metadata. It does not ship a Laravel service provider, Laravel configuration, or Eloquent integration, so it is not a drop-in Laravel package.
- Can I install ibrows/import-bundle in Laravel 10 or Laravel 11?
- Composer will almost certainly block installation because the bundle targets older Symfony and PHP constraints than Laravel 10 or 11 allows. Using --ignore-platform-reqs would bypass the check but would not make Symfony's kernel or DI container load inside Laravel. Even if the files land in vendor/, the import services would not be registered or usable.
- What does ibrows/import-bundle actually do?
- It provides a reusable foundation for data import workflows: configurable import definitions, source-to-model field mapping, pluggable readers and processors, validation, and error handling. In a Symfony app it is intended to support batch ingestion into Doctrine entities or custom services. For Laravel teams, its main value is as a requirements and design reference rather than shippable code.
- Does ibrows/import-bundle support CSV, XML, and Excel imports?
- The overview describes pluggable readers and processors but does not name supported formats, so CSV, XML, and Excel support must be confirmed by reading the source. The TPM assessment explicitly flags whether the bundle is CSV only or CSV/XML/Excel as a question to answer before estimating. Do not assume Excel support from the bundle description alone.
- Which Symfony and PHP versions does ibrows/import-bundle require?
- The provided excerpt does not include composer.json, so exact constraints are unknown. The TPM assessment expects PHP 5.6/7.0-era code and Symfony 2/3-era scaffolding, with no upstream maintenance. Check composer.json for PHP, Symfony, and Doctrine constraints before any evaluation.
- Is ibrows/import-bundle maintained and safe for production?
- Treat it as unmaintained. The package has 0 stars and 0 dependents, which means no external production use, no security review, no issue triage, and no user base to consult. A consultancy-released bundle with zero traction is often delivery scaffolding left after a client engagement, so production use carries high technical risk.
- What licence does ibrows/import-bundle use?
- The licence is not stated in the provided overview or README excerpt. Consultancies commonly publish bundles without a clear licence, so confirm the licence file and terms before any code enters your repository. A licence gap is a legal risk that should be surfaced before adoption or forking.
- How do I use ibrows/import-bundle with Doctrine ORM 3 and PHP 8.1+?
- Likely not without changes. The TPM assessment warns that PHP 8.1+, Doctrine DBAL 3/4, and ORM 3 remove or change APIs common in importers of this vintage, including EntityManager::merge, ClassMetadataInfo, and Statement::execute. Fatal errors mid-import are a realistic failure mode, so a fork would need a compatibility audit and likely persistence rewrites.
- Can I fork ibrows/import-bundle and port it to Laravel?
- Forking is technically possible but usually costs more than a greenfield Laravel build. You would copy the code into packages/, strip the Symfony bundle class and DI extension, expose services through a Laravel service provider, and either bind Doctrine or rewrite persistence to Eloquent. The TPM assessment frames this as a build-plus-port task, not a shortcut.
- What are the best Laravel alternatives to ibrows/import-bundle for CSV imports?
- For Laravel, evaluate league/csv or spatie/simple-excel for framework-native CSV ingestion, and maatwebsite/excel if you need Excel files. For hosted import surfaces with mapping and validation, consider Flatfile, OneSchema, or csvbox. Use ibrows/import-bundle only as a specification for stages like read, validate, and persist.