Lavarle Laravel Package

Getting Started

Lavarle is a grab-bag of macro/service-provider sugar for Laravel — model introspection helpers, collection/string/route/response macros — registered through a single service provider. It's archived and deprecated, so treat it as reference source you copy from rather than a dependency you install.

Minimal setup if you still want it wired up:

composer require tomasvotruba/lavarle

• Laravel 5.5+: package auto-discovery registers Lavarle\ServiceProvider; nothing else to do.
• Laravel <5.5 or Lumen: add the provider manually to config/app.php (providers array) or bootstrap/app.php.
• Confirm it loaded: php artisan tinker, then dump the macros on Collection, Str, Route, and Response — the provider registers them in boot(), and that macro list is the package's API surface.

Where to look first: the provider's boot() method, then the per-class macro registrars (model/collection/route). There is essentially no documentation beyond the README and blog posts, so the source is the spec. Read the trait/macro files and note the method names, because a lot of them will collide with behaviour Laravel has since added natively.

First real use case: schema-aware Eloquent helpers. Instead of hand-writing DB::select('PRAGMA table_info...') in a generator or seeder, you get things like column and foreign-key introspection off the model. That's the 20% of the package that earns its keep — the rest is convenience.

Implementation Patterns

Introspection in code generators and seeders. The highest-value pattern is using model/table helpers inside Artisan commands — building factory stubs, generating migration skeletons, or dumping a schema map for a domain. Call it from a command, not from controllers; it's tooling code, not request-path code.

Route/action helpers for refactor safety. Lavarle's routing macros let you point at a controller class + method rather than a hardcoded URI string. Use this when you're actively moving controllers around and want the linker to break loudly. In a stable app, native route() with named routes is still the better default — don't mix the two styles.

Macros as app-level sugar. Because everything is a macro, your own code reads natively:

$model->getTableColumns();          // schema shape without raw SQL
collect($rows)->toArrayRecursive(); // flatten nested payloads for JSON/CSV export

Wrap each one you actually adopt in a thin app-level helper (app/Support/Schema.php) so a future Laravel upgrade that clobbers the macro name only breaks one file.

Collection helpers in report/export pipelines. Recursive array conversion and grouping/chunking are the useful ones when flattening Eloquent results into CSV or spreadsheet rows. Keep them at the edge of the pipeline (output formatting), never inside domain logic.

Integration tip — vendor it. Given the package is dead, the sane "implementation" is: copy the macro classes you need into app/Support/Lavarle/, register them from your own AppServiceProvider, and delete the dependency. You get the utility, you own the upgrade path, and Composer stops warning you.

Gotchas and Tips

• It's deprecated and unmaintained. Zero stars, zero dependents, archived repo. Don't ship it to production as a requirement; fork or vendor the handful of methods you want.
• Macro name collisions are the main hazard. Laravel has since added many equivalents natively (Str::of(), richer collection methods, Model::getConnection()->getSchemaBuilder()). A macro registered later wins, so you can silently shadow or be shadowed depending on provider order. Dump the macro list after install and diff it against what you expect.
• No docs. Method names in blog posts drift from the code. Always read the macro file before using a method; type errors from a wrong signature look like Laravel bugs but aren't.
• Provider auto-discovery only covers 5.5+. On Lumen or older Laravel, forgetting the manual registration gives you "method does not exist" at runtime with no hint that the package is the cause.
• Macros leak across tests. Macros are registered once per process, so a macro shadowing a core method in one test file affects others in the same PHPUnit process. Register in boot() (not register()) and assert behaviour explicitly rather than relying on ambient discovery.
• Schema introspection is driver-specific. Column/FK helpers that work on MySQL may return nothing useful on SQLite or Postgres. Test against the same driver you deploy on — this bites hardest in CI, which usually runs SQLite in-memory.
• Extension point worth knowing: if you do keep it, re-register the macros yourself in AppServiceProvider::boot() and disable auto-discovery ("extra": {"laravel": {"dont-discover": ["tomasvotruba/lavarle"]}}). That gives you one place to patch a broken macro without editing vendor/.
• Debugging tip: composer dump-autoload after any hand-edit in vendor/, and if a macro vanishes, check composer update bumped the package — it's unpinned-risk territory since nothing downstream depends on it.