Laravel Base Laravel Package

Getting Started

• Check constraints before installing. This is a 2016-era package; run composer show zulfajuniadi/laravel-base --all and read its composer.json require block. It targets Laravel 5.1/5.2 and PHP 5.5/5.6. On a modern app, either pin to an old skeleton or fork — a straight composer require zulfajuniadi/laravel-base will likely fail dependency resolution.
• Install (on a compatible app): composer require zulfajuniadi/laravel-base.
• Register the provider manually. There is no package auto-discovery in this era. Open config/app.php and add the package's *ServiceProvider (look under vendor/zulfajuniadi/laravel-base/src/) to the providers array. Add any facade aliases to aliases if the README lists them.
• Publish config/assets if offered: php artisan vendor:publish. Look for a base.php (or similarly named) config that holds the "sensible defaults."
• Read the source first. The package's entire value is its abstract base classes and traits. Skim vendor/zulfajuniadi/laravel-base/src/ — it is a small codebase, and its behavior is defined entirely by those abstract class / trait declarations, not by documentation.
• First use case: create one model and one controller that extend the package's base classes, wire a single resource route, and verify the defaults (timestamps, soft deletes, JSON error shape, fillable/guarded) match your expectations before building anything on top.

Implementation Patterns

• Extend the base model for shared behavior. class Post extends BaseModel inherits any common boot logic (UUIDs, slugs, casts, global scopes). Keep domain-specific logic in your own traits on top of the base class, rather than editing vendor.
• Resource controllers over hand-written CRUD. If a BaseController ships, use it for the standard index/show/store/update/destroy flow and override only the hooks — validation rules, model resolution, response formatting — instead of duplicating action bodies.
• Validation in form requests / base rules. Centralize rule arrays in the base abstract and extend per resource so error responses stay consistent across endpoints.
• Consistent API envelopes. If the package provides response helpers or macros, route every controller through them so success/error shapes don't drift between endpoints.
• Testing. If the package ships a TestCase, extend it so database traits and fakes are configured identically across all tests.
• Wrap it. Because the package is stale, don't extend its classes directly in dozens of files. Create your own App\Base\Model and App\Base\Controller that extend the package classes, and extend those everywhere. Swapping the package out later becomes a one-file change.
• Compose, don't inherit deep. Prefer adding package traits to your own classes over building a deep inheritance chain off the base classes — small packages often have magic in boot* methods that are hard to trace through three levels.

Gotchas and Tips

• Age is the primary gotcha. Last release April 2016 and only 30 stars mean it is effectively unmaintained. Treat it as a reference implementation or a fork starting point, not a dependency you upgrade casually.
• Missing provider registration is the most common first failure — you'll see "class not found" or "target class does not exist" when calling any helper the package registers. Double-check config/app.php.
• Mass-assignment surprises. Base models often set $guarded = [] or an empty $fillable for convenience. Audit that before exposing a model to $request->all().
• Global scopes and boot* methods apply to every extending model and can silently restrict queries (soft deletes, tenancy filters, ordering). If queries behave oddly, check the base model's boot logic first.
• Debugging "magic" base methods: get_class_methods(SomeBase::class) in tinker, or read the trait directly — the source is short and faster than guessing.
• Never edit vendor/. Publish configuration, copy abstract classes into App\Base\, or fork the repo if you need changes.
• Extension points are the protected hooks on the base classes (rule providers, model resolvers, response builders). Use those; subclassing and overriding public methods tends to break the shared flow.
• Verify the config file is actually loaded — an empty published base.php is a common outcome when the provider is missing or the publish tag is wrong; dd(config('base')) is a quick sanity check.