- Can I install jgrygierek/batch-entity-import-bundle in a Laravel application?
- No. It is a Symfony bundle coupled to bundle registration, the DI container, HttpKernel, EventDispatcher, and Doctrine ORM entities, so it will not install or boot inside an Illuminate application. If you are on Laravel, use it as a design reference for the upload, stage, preview, edit, validate, commit workflow rather than as a dependency.
- How do I install and register the batch entity import bundle in Symfony?
- Install it with Composer using the jgrygierek/batch-entity-import-bundle package name, then register the bundle in your Symfony kernel and configure it through its DI extension. The exact keys for column mapping and chunk size should come from the README, and you should confirm them with a short spike in a throwaway Symfony skeleton before committing to adoption.
- Which PHP and Symfony versions does this bundle support?
- The available material does not pin exact constraints, so check composer.json for the symfony/*, doctrine/orm, and PHP requirements yourself. This matters because an abandoned bundle on an older Symfony major will pull in unsupported transitive dependencies. Verify both against your current runtime before planning any adoption.
- How does the preview and edit step work and where is the staged import data stored?
- The bundle stages imported rows so you can preview and edit them before entities are persisted, but it is not confirmed whether that state lives in the database, the session, or in memory. That answer determines your PII exposure and cleanup obligations, so read the source or run a spike and inspect what tables or session keys appear. Do not assume it cleans up after itself.
- Does the bundle stream large CSV files or load the whole file into memory?
- The description claims configurable chunk sizes for efficient, low-memory processing of large datasets, but it is not confirmed whether parsing streams row by row or buffers the full file first. Test with a representative file at your real size limit and watch peak memory before trusting the claim in production. File format support beyond CSV, such as XLSX, is also unverified.
- How are entity relationships and duplicate rows resolved during import?
- This is an open question rather than a documented feature. Entity resolution and relation lookups are exactly the logic you would have to rebuild for a Laravel port, so read the source to see how it matches existing records and what it does with duplicates. If your import involves foreign keys, verify the behavior in a spike before designing around it.
- What happens on partial failure, is the import all-or-nothing or per-row isolated?
- This is not confirmed in the available material. Per-row isolation with a row-level error report is far more useful for admin bulk uploads, while an all-or-nothing flush is simpler but expensive to retry on large files. Test a deliberately broken file in the spike and note whether valid rows commit or the whole batch rolls back.
- Is there a programmatic API or is the import feature UI-only?
- Unknown from the material provided. The value proposition is a staged preview-and-edit pipeline, which suggests it is at least partly UI-bound. If you need scheduled ETL rather than human uploads, confirm there is a service you can call directly instead of driving a controller. That answer decides whether it fits migrations and cron jobs at all.
- What is a good Laravel alternative for bulk CSV imports with a preview step?
- There is no drop-in equivalent because this bundle is Symfony-only, so you reimplement the pattern natively. In Laravel that means a staging table or model, a preview and edit surface in Nova, Filament, Livewire, or Blade, row-level validation, relation lookups, and a transactional commit with rollback. Expect low single-digit engineer-weeks for a first entity type, more as relationships and file formats expand. Laravel Excel handles parsing and chunked reads while you build the preview and commit layers.
- Is jgrygierek/batch-entity-import-bundle actively maintained and safe for production?
- Project health is the main risk, with roughly 12 stars and zero dependents meaning almost no external validation, no downstream bug reports, and no guarantee of PHP or Symfony version tracking. It is also a single-maintainer project, and the last release timestamp looks like a data-quality anomaly worth verifying on Packagist directly. The MIT license is the one clear positive, so forking and vendoring into your own namespace is legally clean if you decide to own it.