Laravel Common Laravel Package

Getting Started

reliqarts/laravel-common is a small, low-adoption utility package (2 stars, 0 dependents) of base classes and helpers from Reliq Arts. Treat it as an internal-style toolkit rather than a community-maintained dependency, and verify its contents against your Laravel version before committing.

1. Inspect before install. Clone or browse the repo and read composer.json first. Check the require block for the Laravel/illuminate version constraint — a package this size is unlikely to track every new major. Confirm it supports your app's Laravel version and PHP version.
2. Install into a scratch branch.

   composer require reliqarts/laravel-common
   

   If the constraint blocks install, do not use --ignore-platform-reqs blindly — inspect the code for version-sensitive APIs first.
3. Check for a service provider. Look for src/*ServiceProvider.php. If it's Laravel-auto-discovery compatible it will register itself; if not, add it to config/app.php providers manually.
4. Look for publishable config/migrations.

   php artisan vendor:publish --provider="ReliqArts\Common\...ServiceProvider"
   

   Read what it publishes before running it in a real app.
5. Read src/ top to bottom. This is the real documentation. It is likely a handful of files: base model/controller/repository classes, traits, and global helper functions. Note the namespaces and any global function names.
6. First use case. The highest-value, lowest-risk entry point is usually extending a base model or base controller in a new, small CRUD feature, or calling one or two helper functions in a throwaway/internal project. Do not retrofit it into a large existing codebase on day one.

Implementation Patterns

Extend the base classes rather than composing them. Base/common packages typically assume inheritance:

use ReliqArts\Common\Models\BaseModel; // verify actual namespace

class Post extends BaseModel
{
    // inherits whatever conventions the package bakes in
}

Check what the base class actually does — fillable guards, UUID/timestamp handling, casts, soft deletes — before assuming it's a no-op.

Use the traits selectively. If the package ships traits (e.g. for slugging, status columns, or API responses), apply them per-model/per-controller instead of adopting the whole base class. This keeps the blast radius small and makes removal easy later.

Wire helper functions deliberately. If it registers global helpers, confirm they're autoloaded via the files key in composer.json and that names won't collide with Laravel's own helpers or your app's. Use them in new code, not as a refactor target for existing code.

Wrap base-class behavior behind your own contracts. For anything you plan to keep, define your own interface or abstract class that extends the package class. That way, when the package goes unmaintained (likely, given adoption), you can swap the parent without touching consumers.

Integration approach — new projects vs. existing apps.

• New project: pick the pieces you need (base model + a couple of traits) up front, document the convention in your README, and make sure every new model/controller follows it consistently.
• Existing app: introduce one feature behind the package, write tests around it, and keep it isolated to a namespace you control.

Vendor/fork for anything long-lived. A two-star package with zero dependents is a single-maintainer risk. Fork it into your org, tag a version, and require your fork via a VCS repository. This is the difference between "utility" and "unmaintainable dependency."

Gotchas and Tips

• Adoption is essentially zero. With 2 stars and 0 dependents, there is no community safety net: no Stack Overflow answers, no third-party tutorials, no bug reports from others. You are the QA.
• Version drift is the top risk. Read the illuminate/* constraints and test on your exact Laravel minor. Base classes that touch Eloquent internals break quietly between majors.
• Global helper collisions. If the package autoloads function files, function names live in the global namespace. Grep your app and other dependencies for conflicts before install; a duplicate function declaration is a fatal error, not a warning.
• Auto-discovery assumptions. Without a registered extra.laravel.providers, nothing boots. If helpers/config appear missing, this is the first thing to check — add the provider path to bootstrap/providers.php (Laravel 11+) or config/app.php.
• Undocumented base-class behavior. Base models often impose $guarded = [], timestamps, or casts implicitly. Dump the parent's properties and boot* methods before you rely on defaults.
• Debugging. You'll be reading vendor/reliqarts/laravel-common/src constantly. Consider a path repository override during development so you can add dump()/dd() and diff against upstream easily.
• Extension points are unknown. Since docs are thin, don't assume protected methods exist to override. Treat the package as sealed and extend via composition rather than overriding internals.
• Testing. Add your own tests around every base class and helper you adopt. There's no guarantee upstream tests cover your use case.
• License is MIT — you can fork and vendor freely. Given the maintenance signals, plan for that by default rather than as a fallback.