Hotel Card Delivery Bundle Laravel Package

Getting Started

There is essentially nothing to go on here except the version tag: 0.0.1, first public release, changelog link only (no notes, no README excerpt, no dependency data). Treat everything below as a starting checklist to verify, not as documented behaviour.

• Install: composer require tourze/hotel-card-delivery-bundle:0.0.1 (pin the exact version — see Gotchas).
• First place to look: the bundle entry class (*Bundle.php) in src/, then DependencyInjection/Configuration.php and DependencyInjection/*Extension.php. Tourze bundles are consistently structured this way, and the extension tells you more about the package's real surface area (entities, services, config tree) than any README will at 0.0.1.
• Second place to look: the Doctrine mapping (attributes or Resources/config/doctrine/*.orm.xml). For a "hotel card delivery" domain the entities (HotelCard, CardDelivery, CardDeliveryTask-ish) are the actual product; the bundle is the glue.
• Reality check before you build anything: this is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no config/*.php to publish, no facade, no migrations directory. If you are committed to Laravel, the realistic first use case is: install the pure-domain sibling package (typically tourze/hotel-card-delivery without the -bundle suffix) and hand-wire it — see Implementation Patterns.
• First use case to prove out: create a delivery record for a card, persist it, and read it back. That validates the entity mapping, the repository wiring, and the ID/identifier strategy in one pass — which is where 0.0.1 packages break first.

Implementation Patterns

If you are actually on Symfony (the supported path):

• Register the bundle in config/bundles.php, add a minimal config block (the extension almost certainly has a nearly-empty tree at 0.0.1), and let the bundle's Doctrine mapping autoload.
• Consume the injected repository/service rather than the entity manager — tourze packages lean heavily on constructor-injected, interface-bound services; the repository interfaces are the stable seam to code against.

If you are on Laravel (the stated framing), the bundle is mostly unusable as-is; three workable patterns:

1. Domain-only consumption (recommended). Require the non-bundle package, composer dump-autoload, and bind the domain interfaces in your own AppServiceProvider. You get the entities and services, and you skip the Symfony container entirely.
2. Mapping transplant. Copy the Doctrine mapping definitions into your app/Models or a database/migrations set by hand. Do this once and own it — do not try to point Laravel's Doctrine integration at a path inside vendor/, it will bite you on every composer update.
3. Bridge via a Symfony-container shim (e.g. a bundle-registration bridge). Only worth it if you also consume several other tourze bundles and want one integration to cover them all. For a single package, it is more overhead than it saves.

Integration tips regardless of framework:

• Wrap the package behind a thin application-level interface (CardDeliveryService) of your own. At 0.0.1 the public API will move; your wrapper is the thing that survives.
• Keep delivery side effects (printing, encoding, notifying the front desk) outside the package. A *Bundle named "delivery" typically models the record and its state, not the physical act — assume the actuation is yours.
• If the package ships status enums or workflow transitions, back your own tests with them now; this is the cheapest time to discover the state machine doesn't match your front-desk reality.

Gotchas and Tips

• 0.0.1 means zero BC promise. Pin 0.0.1 exactly (no caret) and keep composer.lock committed. Expect the namespace or entity property names to change before 0.1.
• Symfony-bundle assumptions in a Laravel app. Symptoms you'll hit: mappings not registered, services not resolvable, "class not found" on interfaces that are only bound by the bundle's extension. Debugging tactic: read the extension's load() method; whatever it registers is exactly what you must replicate in a service provider.
• Dev dependencies leaking. Tourze packages frequently require sibling tourze/* packages at dev-master or *@dev in require-dev. If composer require drags in unstable constraints, that's why — check composer why-not and set "minimum-stability": "dev" with "prefer-stable": true only as a last resort.
• No documentation at 0.0.1. The changelog link is the entire release note. Your authoritative sources are, in order: the DI extension, the entity mappings, the test suite (if present). If there is no tests/, treat the package as unverified sample code and write your own characterisation tests before depending on it in production.
• Extension points to look for: compiler passes (they reveal optional integrations), tagged services (listeners/subscribers on delivery events), and the config tree (even a near-empty tree tells you what the author intended to make configurable).
• Debugging on Symfony: bin/console debug:container --tag=... and debug:config <alias> are the fastest way in. On Laravel, php artisan tinker plus app()->make() on the domain interface will fail loudly and usefully if a binding is missing.
• Verdict for this release: fine to evaluate in a spike, premature for production. Re-read this assessment at 0.1.0 — the first minor bump is where the entity shape and namespace will settle, and where a real changelog is likely to appear.