- Is nicolas-souffleur/mapping-connector-bundle a Laravel package?
- No. It is a Symfony bundle built as an Akeneo PIM connector that registers readers, processors, and writers as Akeneo import/export jobs. It cannot be required into a Laravel application and used as a library. Its only realistic value to a Laravel team is as reference material for the mapping model.
- Can I install this package in a Laravel project with Composer?
- Practically no. Although it is distributed on Packagist, its constraints target Symfony 3.4/4.x, PHP 7.x, and Akeneo 2.x/3.x, so a modern Laravel install will fail dependency resolution on Symfony or Doctrine. Even a forced install would not give you anything callable from Laravel.
- What does this package actually do?
- It provides configurable mapping definitions between source and target data structures, used to transform arrays, objects, and DTOs through reusable connector mappings. In Akeneo it imports and exports products with specific column names, maps them to Akeneo attributes, and generates the CSV you need. It replaces hand-written conversion code inside Akeneo jobs.
- Which Akeneo versions does this bundle support?
- The last release was 2019-02-21, which places it in the Akeneo 2.x/3.x era with PHP 7.x and Symfony 3.4/4.x. Nothing indicates support for Akeneo 4.x, 5.x, 6.x, or 7.x on PHP 8.1+. Run a Composer resolution spike in a throwaway sandbox before assuming anything newer works.
- Is this package still maintained?
- No meaningful maintenance. There has been no release in roughly six years, it has a single maintainer, and there is no evidence of active issue triage. It has 11 stars and zero dependents, so the compatibility matrix has essentially never been exercised outside the author. Treat it as abandoned.
- How do I map CSV columns to Akeneo attributes in a Laravel application?
- Do not integrate this bundle for that. Reimplement the pattern natively: a config-driven column-to-attribute map plus a CSV reader and writer, which is not complex domain logic. The bundle is useful as a design reference, not as runtime code in a Laravel stack.
- Does it support localisable, scopable, metric, price, or reference-data attributes?
- Coverage is unknown and unproven. The bundle is CSV-centric, and there is no visible test suite demonstrating per-attribute-type handling, especially in the areas where Akeneo mapping usually breaks. You would need to prove each attribute type you use individually before committing.
- Is it safe to use in production?
- High risk. There is no patch cadence, and its PHP 7 and Symfony 3.4/4.x transitive dependencies carry known CVEs. With zero dependents there is no evidence of production validation, and no visible CI or test suite to lean on. Only adopt it behind a hard go/no-go spike and with a fork you control.
- Can I fork this bundle and maintain it myself?
- Yes, and that is the only sane adoption path if you already run Akeneo. Fork it into your own namespace, pin and audit transitive dependencies, add a minimal test suite covering each attribute type you use, and publish internally. Never depend on the upstream repository directly, and retire the fork once a first-party connector replaces it.
- What are the alternatives for Akeneo product import and export mapping?
- For Akeneo, use native connectors or a custom first-party bundle you own, and consider API-level sync if CSV is only a proxy. For a Laravel-only stack, write a small config-driven mapper and CSV writer yourself rather than pulling in Akeneo plumbing. This package does not address API-level synchronisation at all.