Model Laravel Package

Getting Started

The package is published as kyzegs/model (v0.1.0). It is an early-stage package, so treat the README and source as the source of truth rather than assuming a stable public API.

Minimal steps:

1. Install it:

   composer require kyzegs/model
   

2. Confirm the installed version and its constraints:

   composer show kyzegs/model
   

3. Check whether the service provider is auto-discovered. If not, register it in config/app.php.
4. Look first at:
   • the package README (usage examples),
   • src/ for the main model/trait/service class,
   • any config/ or database/ directories for publishable assets,
   • the package tests for intended behaviour.

A sensible first use case: pick one existing Eloquent model, apply the package’s base model or trait to it, and verify normal Eloquent behaviour still works (fill, save, relationships, factories). Do not start by swapping every model in the application.

Because v0.1.0 explicitly adds Laravel 10 support, verify your app’s Laravel and PHP versions match the package’s composer.json constraints before adopting it.

Implementation Patterns

Incremental adoption. Apply the package to a single model first, run your existing test suite against it, then expand. This is especially important at v0.1.0 where behaviour may change between patch releases.

Base model pattern. If the package provides a model base class, extend it in place of Illuminate\Database\Eloquent\Model:

use Kyzegs\Model\Model;

class Post extends Model
{
    //
}

Keep your relationships, casts, accessors, and $fillable definitions unchanged; the package should compose with standard Eloquent rather than replace it.

Trait pattern. If the package exposes a trait, add it to existing models instead of changing their parent class. This is the lower-risk integration path and makes rollback easy.

Config publishing. If the package ships configuration, publish it and commit it so environment-specific behaviour is explicit:

php artisan vendor:publish --provider="Kyzegs\Model\ModelServiceProvider"

Testing workflow. Add a focused feature test for the first model using the package. Cover create/update, a relationship, and serialization (toArray/toJson). This catches most integration surprises early.

Factories and seeders. Confirm the package model works with Laravel factories and seeders before relying on it in local development or CI fixtures.

Gotchas and Tips

• Early-stage API. v0.1.0 is the first release. Pin the version in composer.json and read the changelog before upgrading. Expect naming and API adjustments in future releases.
• Package rename. The release notes mention a rename. Confirm the actual Composer package name and PHP namespace from composer.json and src/, and make sure you are not referencing an older name in imports or provider registration.
• Laravel 10 support is not the same as Laravel 10-only. The release adds Laravel 10 compatibility; check whether older Laravel versions remain supported or whether the constraint is now ^10.0. Match this against your application’s version before installing.
• Auto-discovery. If the package’s provider is not auto-discovered, missing provider registration produces confusing “class not found” or trait-not-applied errors. Run php artisan package:discover after installation.
• Namespace confusion after a rename. If the package was renamed, documentation snippets may still use an older namespace. Trust the installed source under vendor/kyzegs/model/ over blog posts or older examples.
• Debugging. Use composer show kyzegs/model, inspect vendor/kyzegs/model/composer.json, and run composer dump-autoload after changes. If behaviour differs from stock Eloquent, compare the package’s base class/trait against the Eloquent methods it overrides.
• Extension points. Prefer overriding methods in your own model or publishing config over editing vendor files. If the package dispatches events or exposes hooks, use those rather than patching internals.
• Documentation gap. With a v0.1.0 package, tests are often better documentation than the README. Read the package’s test cases to understand expected inputs, outputs, and edge cases before building on them.