Support Laravel Package

Getting Started

• Install with composer require rinvex/support. Before you do, open the package's composer.json and check the php and illuminate/* constraints—the package targets Laravel 6–8 era releases and will refuse to install on newer Laravel versions without a fork.
• Laravel auto-discovery registers Rinvex\Support\Providers\SupportServiceProvider. That provider is the entry point: it loads the package's helpers file, binds the package contracts, and registers the custom validation rules. Skim it first—it is the map of everything the package does.
• Publish anything you want to override:

  php artisan vendor:publish --provider="Rinvex\Support\Providers\SupportServiceProvider"
  

  Inspect the publish tags in the provider to see what is available (config, views, translations).
• Where to look next, in order:
  1. src/Validators/CustomValidator.php — the extra validation rules the package adds on top of Laravel's built-ins.
  2. src/Http/Controllers/BaseController.php — a CRUD scaffolding controller that subclasses Illuminate\Routing\Controller.
  3. src/Traits/ and src/Contracts/ — the shared behavior surface used by other Rinvex packages.
  4. src/helpers.php — global helper functions loaded via Composer's files autoload.
• First concrete use case: extend BaseController for an admin CRUD screen, or use one of the custom validator rules in a FormRequest as soon as the service provider is registered. Both are single-file wins that do not require you to adopt the rest of the package.

Implementation Patterns

• CRUD via BaseController. Subclass it, then set the four protected properties it expects: $repository (a repository instance), $resource (the Eloquent model class), $viewPrefix, and $routePrefix. The base class then implements index, show, create, store, edit, update, and destroy, delegating persistence to the repository and rendering views under $viewPrefix. Your concrete controller only needs to override validation rules and add hooks where your domain differs (e.g., eager-loading, filters, authorization).
• Form requests stay yours. BaseController deliberately leaves validation to you. Keep store/update rules in FormRequest classes and override the base's validation method so authorization and messages stay idiomatic Laravel.
• Custom validator rules. Once the provider is booted, the extra rules from CustomValidator are available by name inside Validator::make/FormRequest rules arrays. Confirm the exact rule names in CustomValidator.php—do not guess from documentation, since the package is unmaintained and rules have shifted across versions.
• Register additional rules the same way. If you need more rules, register them in your own service provider's boot using Validator::extend / Validator::replacer. The package itself uses this pattern, so extending it is straightforward.
• Contract binding. The package's contracts are intended to be bound in a provider. In Laravel you can rebind them in AppServiceProvider::register to swap implementations without touching the package—this is the cleanest extension point.
• Traits on models. Traits in src/Traits/ are designed to be dropped into Eloquent models (use SomeTrait;). Check each trait's required columns and any boot methods it adds before applying them; several Rinvex traits mutate behavior via boot* methods and expect specific schema columns.
• Helpers. The helpers.php functions are globally available after autoload. Wrap them in your own small service if you want to isolate application code from the archived package and make future removal (or replacement) easier.
• Integration flow for existing Rinvex packages. When another Rinvex package requires rinvex/support, treat this as a peer dependency: keep the version pinned, let it resolve the shared contracts, and avoid extending its base classes deeper than one level so an eventual replacement is not a rewrite.

Gotchas and Tips

• Archived = frozen. No security fixes, no Laravel 10/11 support, no PHP 8.2+ fixes. Pin the exact version in composer.json and add a conflict entry if your app ever moves to a newer Laravel; the safest long-term move is to fork it into a packages/ directory you control.
• Repository dependency. BaseController types its $repository against a repository contract (from the Rinvex repository package family). You cannot use BaseController with a plain Eloquent model—either install the matching repository package or vendor/copy the base controller and replace the type hint.
• Rule name collisions. Several rules the package adds (e.g. uuid) later became Laravel built-ins. On newer Laravel the package's registration may shadow or be shadowed by Laravel's, producing inconsistent behavior. Audit rule names against Illuminate\Validation\Concerns\ValidatesAttributes.
• Global function collisions. Because helpers are autoloaded via Composer files, two packages defining the same function name will fatal at boot. When you see Cannot redeclare function …, this is the cause; you can only avoid it by not installing both packages or by aliasing calls.
• Auto-discovery surprises. If you disable package discovery (dont-discover), remember to register the provider manually; otherwise the validator rules and helpers silently disappear. Symptom: Method [validate*] does not exist or Call to undefined function.
• View prefix mismatch. BaseController renders $viewPrefix . '.index' etc. A missing trailing dot or a mismatch with your resources/views layout produces 404s on views rather than controllers. Dump the resolved view name in one method to confirm.
• Debug validator registration. In php artisan tinker, run Validator::make([], [])->getRules() or inspect app('validator') extensions to see which rules exist. This is the fastest way to know whether the provider booted and which rules the package actually contributed.
• Test the base controller you inherit. The archived code has no test suite. Add one smoke test per overridden action (list, show, store, update, destroy) with a real repository binding; this catches breakage when you upgrade Laravel or replace the repository layer.
• Extension points to prefer. Configuration publishing, contract rebinding in AppServiceProvider, and overriding methods in your own subclass are safe. Reaching into package internals (protected properties, protected function overrides beyond documented hooks) is fragile—record exactly what you override so a fork stays possible.