Weave Code
Laravel Bookings Laravel Package
rinvex/laravel-bookings
Rinvex Laravel Bookings provides a flexible booking system for Laravel applications, with Eloquent models, migrations, and configurable services, resources, availability, and pricing to manage reservations and schedules with ease.
⚠️ [ABANDONED] Rinvex Bookable is a generic resource booking system for Laravel, with the required tools to run your SAAS like services efficiently. It's simple architecture, accompanied by powerful underlying to afford solid platform for your business.
Frequently asked questions about Laravel Bookings
- Is rinvex/laravel-bookings still maintained?
- No. The repository is archived and the package is marked abandoned, so it receives no security patches, bug fixes, or Laravel major version upgrades. Composer will still resolve it from Packagist today, but you should treat it as a reference implementation rather than a live dependency. Budget for a fork or a reimplementation instead of inheriting it directly.
- How do I install and configure rinvex/laravel-bookings?
- Install it with composer require rinvex/laravel-bookings, then publish the package config and migrations with the vendor:publish command before running php artisan migrate. The service provider is conventionally auto-discovered, so manual registration is usually unnecessary. Because the package is archived, pin an explicit version and commit your composer.lock so future installs are reproducible.
- Which Laravel and PHP versions does rinvex/laravel-bookings support?
- The package targets an older Laravel and PHP generation, and its composer.json illuminate/* and php constraints reflect that. Check that single file before planning anything, because it decides whether the package can coexist with your current platform. On modern Laravel releases you should expect to repin those constraints inside a fork.
- Does rinvex/laravel-bookings prevent double bookings and overlapping reservations?
- The package ships no documented overlap or uniqueness enforcement, so starts_at and ends_at are effectively descriptive fields you must guard yourself. Without a transactional check, advisory lock, or database exclusion constraint, overbooking is a matter of traffic rather than luck. The highest-value addition is a Postgres exclusion constraint on the bookable key and time range.
- What is the polymorphic bookable relationship used for?
- Bookings use a bookable_type and bookable_id morph, so any Eloquent model can be reserved without schema forks: rooms, vehicles, equipment, seats, or staff. That flexibility is the package's most reusable idea and composes well with a Resource or Asset model you already have. Remember that morph columns carry no foreign key enforcement, so deletes leave orphan bookings unless you soft delete and prune.
- Does rinvex/laravel-bookings handle timezones and daylight saving time correctly?
- The schema stores booking timestamps, but you need to confirm whether a timezone lives on the booking, on the resource, or nowhere at all. For DST and multi-region correctness, store UTC, keep an explicit timezone, and treat reservations as half-open intervals of [start, end). Do not assume the upstream migration does any of this for you.
- Can rinvex/laravel-bookings handle pricing, payments, recurring bookings, and availability calendars?
- No. It is a persistence and relationship starting point, not a booking engine, so availability calculation, recurring rules, buffer and lead times, capacity above one, pricing, and payment orchestration are all yours to build. Booking types can distinguish reservation semantics but will not express every business rule. If availability logic is your differentiator, inheriting a generic model buys little and costs an abstraction you will outgrow.
- Does rinvex/laravel-bookings support multi-tenancy?
- There is no documented tenant scoping in the package, and Rinvex packages often pair with the separate Cortex tenancy stack instead. Adding a tenant column to a live bookings table later is invasive, so decide before you write any data. If you need row-level isolation, add the tenant key to the migration in your fork from day one.
- How should I test booking logic built on this schema?
- Start at the database level: overlapping intervals, boundary conditions on half-open ranges, DST transitions, and concurrent inserts racing for the same slot. Run feature tests against a real Postgres database rather than in-memory SQLite, because exclusion constraints and transaction isolation are exactly what you are verifying. If you fork the package, keep migration tests so a future Laravel upgrade cannot silently break the schema.
- Should I depend on rinvex/laravel-bookings or fork and reimplement it?
- Never depend on it directly for a production SaaS, because abandonment means no security response and transitive rot as its pinned Illuminate packages age out of support. For a prototype or short-lived internal tool, vendor a private fork with repinned constraints and a fixed version. For a real product, lift the migrations and model design, rebuild them on your current Laravel version, and add conflict prevention and timezone handling yourself.
Weaver
How can I help you explore Laravel packages today?