Certificates For Laravel Laravel Package

Getting Started

• Treat 1.1.3 as the baseline for any host app that customizes package models. This is a patch-level fix: package factories now build the model configured by the host when the default model is swapped. If you do not swap models, the upgrade should be transparent.
• Look first at:
  • the package config file for model mappings / configurable model keys;
  • the package service provider for model bindings or config merges;
  • src/Models for the base models;
  • database/factories for factory classes and how they resolve $model.
• First use case: swap a package model in a test or local host app, then use the package factory and assert the returned instance is your custom model.

// config/package.php (placeholder key names)
'models' => [
    'thing' => App\Models\CustomThing::class,
],

config(['package.models.thing' => CustomThing::class]);

$thing = \Vendor\Package\Database\Factories\ThingFactory::new()->create();

$this->assertInstanceOf(CustomThing::class, $thing);

Implementation Patterns

• Prefer config-driven model swaps over editing vendor files. Set the custom model in config or bind it in a service provider before factories are resolved.
• Keep swapped models compatible with the package contract:
  • extend the package base model where required;
  • preserve table, connection, fillable, casts, and relationship behavior;
  • keep relationship return types and morph maps aligned.
• Use package factories normally in tests and seeders. With 1.1.3, a host-swapped model should be produced without needing to override the factory just to change the model class.
• In tests, swap the model before creating records, then assert both behavior and class:

public function test_package_factory_uses_host_model(): void
{
    config(['package.models.thing' => CustomThing::class]);

    $thing = ThingFactory::new()->create();

    $this->assertInstanceOf(CustomThing::class, $thing);
}

• For broader integration, resolve package models through config or the container in app code rather than hard-coding package model classes. This keeps factories, policies, observers, and relationships consistent with the swapped model.
• If your app needs complex model selection, register the binding in a service provider rather than scattering config() calls. Ensure it runs before package factories are used.

Gotchas and Tips

• Clear cached config after changing model mappings:

php artisan config:clear

A cached config file can make a model swap appear broken even on 1.1.3.

• If a factory still returns the old model, check:
  • the correct config key is being changed;
  • the package reads config at factory runtime, not only at boot;
  • your service provider runs in the right order;
  • the factory is not explicitly overriding $model elsewhere.
• Debug with get_class($model) and by inspecting the factory’s resolved model class. Add a temporary assertion in the test rather than relying on database rows alone.
• Model swaps affect more than factories. Review relationships, foreign keys, morph maps, policies, observers, validation rules, and API resources that may still reference the original package model.
• Ensure custom models use the same table/connection unless you intentionally migrate or configure otherwise.
• 1.1.3 is a low-risk patch, but still run your model-swap tests and package integration tests after upgrading. No breaking changes or deprecations are indicated by the release note.
• Extension points to prefer: published config, service provider bindings, custom model subclasses, and package factory states/callbacks. Avoid forking vendor factory code just to change the built model class.