- What does the baril/smoothie package actually do for Laravel Eloquent?
- Smoothie is a trait-based extension of Laravel's Eloquent layer that bundles four features: fuzzy date handling, mutual many-to-many relationships, orderable model behavior, and closure tables for hierarchical data. It was designed to cut boilerplate for those common modeling patterns. Because it hooks directly into Eloquent internals and model events, it is tightly coupled to the Laravel versions it was written against.
- Is baril/smoothie still maintained and safe to install with composer require?
- No. The repository is archived, the last release was July 2020, and there are zero dependent packages, so it should be treated as legacy source material rather than a supported dependency. A Laravel 5.x or 6.x app on PHP 7.x may still resolve it, but Laravel 9, 10 or 11 projects should assume incompatibility until proven otherwise. For modern stacks, plan on vendoring a fork or replacing each feature instead of adding a normal Composer requirement.
- Which Laravel and PHP versions does Smoothie support?
- Smoothie was released in an era of Laravel 5.x and 6.x on PHP 7.x, and its Composer constraints for illuminate/* reflect that. Before attempting any install, read composer.json and confirm the illuminate and PHP constraints against your target stack. Expect PHP 8.1+ deprecations and Laravel method-signature changes in the query builder, Carbon and Eloquent events that the traits rely on.
- How do I add fuzzy date support to a Laravel model without this package?
- Fuzzy dates are the easiest feature to replace because they are mostly query scopes. Write local scopes such as whereDateBetween or whereApproximateDate on your model, or a small reusable trait in app/Support, and use Carbon for parsing and formatting. That keeps the behavior explicit, testable and compatible with current Laravel and Carbon versions. Only port the Smoothie trait if your existing code already depends on its exact date semantics.
- Can I use Smoothie's orderable trait instead of spatie/eloquent-sortable?
- Functionally the two overlap, and spatie/eloquent-sortable is the safer choice because it is actively maintained and widely used. Smoothie's ordering can also introduce write contention and ordering corruption if records are reordered concurrently, so you need transactions and regression tests either way. If you need custom ordering logic that Spatie does not cover, write a small internal trait rather than maintaining a fork of Smoothie.
- What are closure tables in Smoothie and do I really need them?
- Closure tables store every ancestor-descendant pair in a separate table, which makes tree queries fast at the cost of extra schema and write complexity. Smoothie provides traits and migrations for that pattern, but you take on migration risk and index-tuning work on your target database. If you only need simple parent-child hierarchies, a maintained adjacency-list or nested-set package may be a better fit than porting Smoothie's implementation.
- How do I fork baril/smoothie into my own Laravel application?
- Copy only the traits you actually use into app/Support or a private package, then pin and test them against your target Laravel and PHP versions. Keep the original license and attribution, document who owns the fork, and add regression coverage for model events, migrations and reordering behavior. Avoid pulling in all four feature areas when one or two are needed, and schedule regular upgrade reviews so the fork does not drift.
- What are the biggest risks of adopting Smoothie in a production Laravel app?
- The main risks are abandoned upstream code with no security patches, Laravel and PHP compatibility drift, and behavioral coupling to Eloquent events and the model lifecycle. Closure tables add schema and migration risk, orderable behavior can cause write contention and ordering corruption, and mutual many-to-many relationships can obscure query and pivot design. Fuzzy dates may depend on Carbon or query-builder behavior that changed after 2020.
- How should I test a Smoothie integration or a vendored fork?
- Run a time-boxed compatibility spike in an isolated branch before touching production code, then add integration tests for model events, migrations and concurrency-sensitive ordering. Test migrations against your real schema, especially closure-table indexes and any assumptions about the orderable column. Also confirm transaction behavior for tree moves and reordering, and cover fuzzy date queries with edge cases such as nulls and time zones.
- What maintained alternatives exist for each Smoothie feature?
- For ordering, use spatie/eloquent-sortable; for hierarchies, use a maintained closure-table or adjacency-list package such as staudenmeir/laravel-adjacency-list. Mutual many-to-many relationships can be handled with explicit belongsToMany subclasses or dedicated pivot models, and fuzzy date ranges are usually fine as local query scopes with Carbon. Replacing each feature individually is lower risk than carrying a fork of an archived package through future Laravel upgrades.