Edilabo Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — the single most important fact up front. You cannot composer require it into a Laravel app and boot it: Laravel does not dispatch Bundle classes or Symfony's DI container. If you are Laravel-first, decide early between (a) using it only if the underlying parser/exporter classes are framework-agnostic and wiring them manually, (b) running a small Symfony sidecar, or (c) hand-rolling the mapping. Check composer.json dependencies before committing to either path.

Assuming a Symfony context:

1. composer require yoanbernabeu/edilabo-bundle
2. Register the bundle in config/bundles.php (Flex does this automatically):

   YoanBernabeu\EdilaboBundle\EdilaboBundle::class => ['all' => true],
   

3. Create/check config/packages/edilabo.yaml. The config alias is not always the composer name — read DependencyInjection/Configuration.php to find the real root key.
4. Read src/ first. With 1 star and 0 dependents, the source is the documentation. It should be small enough to read in under an hour; do that before designing anything around it.

First useful exercise: grab a real EDILABO XML sample (SANDRE publishes the format/schemas), drop it into var/edilabo-samples/, and run an import through a controller or a one-off bin/console command. That tells you more than the README will.

Implementation Patterns

Import pipeline. XML file → XSD validation → DTO tree → mapping into your domain entities (site, prélèvement, analyse, laboratoire, commanditaire) → persistence. Keep the raw XML and store a reference (path + hash) on an import record so you can replay and audit.

Export pipeline. Query your domain → hydrate the bundle's export DTOs → serialize → XSD-validate → write/ship. Validate before sending. A malformed EDILABO file to a commanditaire is worse than a late one.

Service injection. The bundle registers an importer and exporter service via its DI extension. Inject them into controllers and commands rather than newsing them up — that keeps you on the supported path.

Console commands. Wrap import/export in app:edilabo:import / app:edilabo:export. Lab teams running files without a web UI is the normal case. Add --dry-run, per-file progress output, and a memory ceiling for large batches.

Queue large imports. Dispatch a job that runs the importer and records per-file status and errors in the DB. A single bad file should not abort a batch of fifty.

Adapter layer — non-negotiable. Do not leak the bundle's DTOs into your Eloquent/Doctrine models. Map through your own DTOs or value objects. This is your only insulation against EDILABO schema versions changing under you.

Storage and audit. Keep immutable copies of every imported and exported XML. These exchanges are contractual; when a lab and a client disagree about what was sent, the file is the evidence.

Events. Emit your own domain events after an import (EdilaboFileImported, etc.). Don't hang behavior on the bundle's internals.

Gotchas and Tips

• Very low adoption. 1 star, 0 dependents, a single recent release. Expect rough edges and missing abstractions. Budget time to read and possibly patch the source.
• Symfony-only. No Laravel service provider. Symfony's Serializer, Validator, and HttpFoundation are likely hard dependencies. This is a potential blocker, not a config quirk — confirm before you scope work.
• SANDRE schema versions. EDILABO has multiple format versions and the XSD is the contract. Pin the schema version you validate against, record it per file, and never assume "it imported" means "it imported correctly."
• Encoding and accents. French lab data is dense with é, è, µS/cm, mg/L. Verify UTF-8 end to end and check the export path specifically — mojibake in a µ is the classic failure.
• Dates and decimals. XML date formats and decimal separators are interoperability traps. Don't assume the bundle normalizes them to your domain's conventions; transform explicitly.
• Config alias mismatch. If YAML config won't load, the root key in DependencyInjection/Configuration.php is almost always the culprit — it need not match the package name.
• Debug imports outside the bundle first. Run xmllint --schema edilabo.xsd yourfile.xml and diff your input against a known-good SANDRE sample. Most "the bundle is broken" reports are input-shape problems.
• Extension points. Look for interfaces around the parser, serializer, and validator. If they exist, implement them rather than subclassing concrete classes. If they don't — likely at this maturity — wrap the whole bundle behind your own service so you can replace it later.
• Plan an exit. Document the schema and your field mappings outside the codebase. With one maintainer and negligible adoption, replacing this package should cost a week, not a quarter.
• Build fixtures. A suite of real but anonymized EDILABO files with round-trip assertions is the only guarantee you'll get. The package won't provide them.