Import Demo Bundle Laravel Package

Getting Started

This is an archived, README-only Symfony demo bundle with zero stars and zero dependents. The README is a single title line, so there is no installation guide, config reference, or API surface to read. Plan on reading source, not docs — and plan on extracting a pattern rather than adopting a dependency.

First, reconcile the framework mismatch: despite being evaluated as a Laravel package, this is a Symfony bundle. Its value proposition is that it demonstrates how endroid/import-bundle is wired into a Symfony app (service definitions, import definitions, a controller example). Bridging a Symfony bundle into a Laravel app is custom work with no payoff here. The pragmatic path is to install it into a throwaway Symfony skeleton purely as reading material, understand the pattern, then reimplement in Laravel.

Suggested reading order in the repo:

1. composer.json — the only reliable signal of the endroid/import-bundle version it demonstrates and sibling demos it expects.
2. DependencyInjection/ — the extension class; source of truth for config keys and defaults.
3. Resources/config/ (or config/) — service wiring for the importer, tagged import definitions, and handlers.
4. Controller/ — smallest end-to-end example of triggering an import.
5. Entity/ or Model/ — the imported model, which reveals the shape of a "row definition."

First use case: in a throwaway Symfony skeleton, composer require --dev endroid/import-demo-bundle, copy the controller + routing into the app, and run an import against a small CSV. Success means you understand how the core import-bundle services are named and how an import definition is registered — not that the demo bundle is doing work for you. Then delete it and add endroid/import-bundle if you actually need the functionality, or implement a thin owned pipeline in Laravel.

Implementation Patterns

The meaningful patterns are the ones you copy out, not ones you use.

• Reference, don't depend. The healthiest integration is composer require --dev, read the example, remove the package, and add endroid/import-bundle (or nothing) as the real dependency. Treat the demo as a living doc snippet, not a library.
• Copy the service wiring. The demo's real value is the canonical container setup: the importer service, import-definition services tagged for discovery, and the mapping between the model and incoming columns. Recreate those definitions in your own config/services.yaml rather than inheriting the bundle's.
• Follow the controller flow. The general shape is portable to a Laravel controller/service or queued job:
  1. Form upload → temporary file.
  2. Resolve the appropriate import definition for the file type.
  3. Call the importer service with the file and the definition.
  4. Iterate the import result to surface row-level errors. Reimplement this in your own code — do not route through the demo's controller.
• Model your own domain. The demo's example entity is deliberately boring so you can see where "row → model" mapping belongs. Extract that into your own import-definition classes in App\Import\Definition\... so application code never references the demo's namespaces and eventual deletion is a no-op.
• Port the test fixture, not the test class. If the demo ships a functional test that runs an import against a fixture file, that test is often the clearest specification of intended behavior. Copy the fixture and the assertions into a Laravel feature test; rewrite the surrounding harness.
• In Laravel, mirror the pattern with native primitives: a Job/Command as the importer entry point, a definition class per import type, league/csv or PhpSpreadsheet for parsing, and a validation/mapping layer that produces a structured result you can report back to the UI.

Gotchas and Tips

• Archived, unmaintained, no security response. Pin to --dev and expect to remove it. Do not let it leak into require.
• Zero stars and zero dependents is a signal, not trivia. There is no community to fall back on; any bug is yours to fix. Keep the coupling shallow.
• The README tells you nothing. Version constraints, PHP/Symfony compatibility, and config keys must all be read from composer.json and the DI extension. Explicitly verify the required endroid/import-bundle version — the demo may be pinned to an old major that has since changed its API.
• Config quirks are undocumented. The extension class is the only source of truth for config keys and defaults. Copy them into your own config file and confirm the container compiles before writing application code.
• Debugging missing services: confirm the bundle is registered in config/bundles.php (or Kernel::registerBundles()), then run bin/console debug:container | grep import to see which services actually exist. A silent empty import usually means missing fixtures or DB setup, not broken wiring.
• Extension points are effectively none beyond the core import-bundle interfaces. Override demo definition classes by replacing them in your own services — never patch the vendor directory.
• Version drift is the biggest practical risk. If the demo targets Symfony 4/5 and you're on 6/7, autowiring, tag names, and Bundle base classes may have shifted. Expect to translate, not install.
• Time-box it. Read for 30–60 minutes, extract the pattern into your own App\Import\* namespace, delete the package, and write a small test that proves your pipeline works end to end. That is the only deliverable this bundle supports.