Melifaro Booking Bundle Laravel Package

Getting Started

The first thing to establish is a framework mismatch: this is a Symfony 2 bundle (the *Bundle suffix, AppKernel registration, Doctrine entities, service container), not a Laravel package. It was last released 2014-04-27, has 35 stars and 0 dependents. For a Laravel developer, the realistic "minimal steps" are: do not install it. composer require melifaro/melifaro-booking-bundle in a modern Laravel app will either fail dependency resolution or drag in an ancient Symfony 2 tree. There is no service provider, no facade, and no Eloquent integration.

If you are evaluating the repository as a reference implementation, look at these first:

1. README.md — the only reliable statement of intended scope.
2. The bundle class (typically Melifaro\BookingBundle\MelifaroBookingBundle) and DependencyInjection/ — shows configuration keys and public services.
3. Entity/ and Resources/config/doctrine/ — the actual domain model (bookable resource, booking record, time fields, status).
4. Resources/config/routing.yml and any controllers — the original user-facing workflow.

The first use case in the original Symfony context is presumably: persist a booking against a bookable resource, then query availability for a time window. Confirm this against the README and entity fields rather than assuming.

For a Laravel app, the equivalent first use case is a bookings table (bookable_type/bookable_id or FK, starts_at, ends_at, status), a Booking model, and a CreateBooking action that checks for overlapping bookings inside a transaction.

Implementation Patterns

In the original Symfony 2 context, day-to-day usage would follow standard bundle patterns: register the bundle in AppKernel, import the bundle routing, set configuration under the bundle's config key, inject the booking manager/repository service into controllers, use Symfony Form types for create/edit, and persist through the Doctrine EntityManager. Availability would be a repository method, and lifecycle behavior would hang off Doctrine events or the Symfony event dispatcher.

In Laravel, do not attempt to bridge Symfony 2 into the framework. Translate the concepts instead:

• Doctrine entities → Eloquent models plus migrations.
• Bundle configuration → config/booking.php and bindings in a service provider.
• Symfony Form types → FormRequests with validation rules.
• Repositories → query scopes or dedicated query/action classes.
• Symfony event dispatcher → Laravel events and listeners (same idea, different API).
• Bundle routing → routes/web.php and thin controllers.

Practical workflow tips for the reimplementation:

• Put the overlap check in the database, not in PHP: where('starts_at', '<', $end)->where('ends_at', '>', $start), scoped to the bookable resource, with an index on (bookable_type, bookable_id, starts_at, ends_at).
• Wrap check-and-insert in a transaction with row locking to prevent double bookings; add an idempotency key for form resubmissions.
• Model status as an explicit state machine (pending/confirmed/cancelled) rather than a boolean.
• Keep booking rules in a domain service so HTTP controllers, console commands, and queued jobs share one path.

If you genuinely need to interoperate during a migration, run the legacy Symfony 2 app as a separate service and communicate over HTTP or a queue. Do not share the Doctrine ORM with Eloquent.

Gotchas and Tips

• Abandoned and EOL. No release since 2014; Symfony 2 reached end of life years ago; the code targets the PHP 5 era. Expect deprecated syntax and no PHP 8 compatibility guarantees.
• Zero ecosystem. 0 dependents and 35 stars means no Stack Overflow answers, no issue triage, and no security patches. Treat every line as unmaintained third-party code.
• Composer conflicts. Symfony 2 constraints clash with modern illuminate/* and symfony/* packages, and the PHP version constraint is likely below 7. Resolution failure is the expected outcome, not a fixable inconvenience.
• Doctrine/Eloquent impedance. Annotations, UnitOfWork, proxies, and lazy-loading semantics do not translate. A half-port that mixes both is worse than a clean rewrite.
• Debugging. There is no Telescope, Clockwork, or Laravel profiler integration. If you fork anything, add explicit logging around availability queries and persistence boundaries first.
• Extension points. In Symfony these were bundle config, tagged services, and events. In Laravel your equivalents are service-provider bindings and events/listeners — decide those before writing booking logic.
• Best use of the package: mine the entity fields and business rules as a specification, then build a small in-house Laravel implementation. A booking domain of this size is typically one to two days of work and will be far cheaper than maintaining a port.
• Recommendation: do not adopt it in a Laravel project. Use it as a reference only, or choose a maintained Laravel booking/time-slot package if you need something off the shelf.