jn-devops/properties
A Laravel package for managing property listings and related data, offering configurable models, migrations, and practical tools to create, organize, and display properties in your application.
This is an internal-style Laravel package (jn-devops vendor, zero stars, zero dependents) — treat it as a private domain package rather than a polished public library. Expect Laravel 9/10-style conventions and a JnDevops\Properties\PropertiesServiceProvider namespace.
First 5 minutes:
composer require jn-devops/properties
php artisan about
php artisan vendor:publish --provider="JnDevops\Properties\PropertiesServiceProvider"
config/properties.php, migrations, seeders, and any model stubs.src/ tree is the documentation. Start with:
src/*ServiceProvider.php (what's bound, what's published, what's aliased)src/Models/ (the domain graph: Property, Unit, Project, Address, etc.)src/Contracts/ or src/Interfaces/ (the extension points you'll actually code against)src/Http/Controllers if it ships routes — check routes/ for what's exposed out of the box.php artisan tinker into the primary model:
App\Models\Property::first();
First practical use case: wiring a Property (or whatever the root aggregate is) into your own form submission — create one record, attach a unit/address, and confirm events fire (see Implementation Patterns).
If the package fails to install or boot: check composer.json for the require block (Laravel version constraint is the usual blocker), and check config/app.php providers array vs. auto-discovery. Given zero dependents, you may be the first person running this against your Laravel version — open the source and check for hardcoded namespace assumptions.
Model extension, not decoration. Most domain packages like this ship base models meant to be extended, not used directly. Add your own model in app/Models/Property.php extending the package base:
use JnDevops\Properties\Models\Property as BaseProperty;
class Property extends BaseProperty
{
// add your domain-specific relationships, scopes, casts
}
Then rebind in a service provider if the package uses a contract:
$this->app->bind(
\JnDevops\Properties\Contracts\Property::class,
\App\Models\Property::class
);
Repository/service layer over the models. If the package exposes a PropertyRepository or PropertyService, inject that rather than querying models directly — it's the abstraction the package author intends you to override and test against. This is also where audit logging and tenancy scoping should live.
Form requests and validation. The package will likely ship validation rules or a StorePropertyRequest. Extend these rather than rewrite — reuse the rules array and add your fields:
class StorePropertyRequest extends \JnDevops\Properties\Http\Requests\StorePropertyRequest
{
public function rules(): array
{
return array_merge(parent::rules(), [
'client_id' => ['required', 'exists:clients,id'],
]);
}
}
Events and listeners. Domain packages almost always fire model/domain events (PropertyCreated, UnitAssigned). Grep for event( and dispatch( in src/ on day one. Hook your integrations (CRM sync, notifications, webhook fan-out) onto these rather than duplicating logic in controllers.
Multi-tenancy integration. In a real-estate domain, properties rarely belong to a single global table. If you're using tenancy (Stancl, Spatie, or a tenant_id column), wrap the package's models with a global scope in a booted() method on your extended model:
protected static function booted()
{
static::addGlobalScope('tenant', fn ($q) => $q->where('tenant_id', tenant()->id));
}
Seeding for dev environments. Use the package's factories (if shipped) or write thin ones. For real-estate data, a PropertyFactory with ->hasUnits(3)->hasAddress() state chains saves hours of setup in tests.
Integration tip — API resources. If you're building an API, don't serialize the package's models directly if it lacks JsonResource classes. Wrap them in your own resources so a future package upgrade doesn't leak or break your contract.
No docs = read the migrations first. The migrations are the source of truth for the schema, and the models are the source of truth for behavior. If there's a conflict, trust the migrations and check for $table, $fillable, $casts overrides in the package models.
Namespace drift is likely. Internal packages often move namespaces between versions (JnDevops vs jn-devops vs Homeful). Check composer.json autoload.psr-4 before assuming a class path. If autoloading fails, composer dump-autoload -o first, then inspect.
Config publishing silently no-ops if the provider tag is wrong. If vendor:publish prints nothing, run:
php artisan vendor:publish --provider="JnDevops\Properties\PropertiesServiceProvider" --tag=properties-config
and inspect the provider's publishes() array literally.
Override the service provider's bindings, not the package source. If you need to change a repository, model, or config default, bind it in AppServiceProvider::register() after the package provider — or use $this->app->extend(). Editing vendor/ is a guaranteed way to lose the change on the next composer update.
Watch for hardcoded table names in migrations. Internal packages sometimes omit a config-driven table prefix. If you need to coexist with existing properties tables, rename yours and set the model's $table explicitly — don't rely on the package picking up a prefix.
Debugging model behavior: when relationships return nothing, log the SQL:
DB::listen(fn ($q) => logger($q->sql, $q->bindings));
Domain packages frequently have HasManyThrough or polymorphic relations (addressable, owner) that fail silently if your foreign keys differ. The polymorphic *_type values must match the package's expected morph map — check for Relation::morphMap() in a provider.
Eager-loading is your responsibility. With properties → units → media → addresses, N+1 hits hard on list views. Add a with() scope on your extended model:
public function scopeForListing($q)
{
return $q->with(['units', 'address', 'media']);
}
Extension points to look for (in priority order): contracts/interfaces bound in the provider → events → config flags → published stubs → base classes. If none exist and you're adding behavior, prefer composition (a wrapper service around the package) over inheritance — it survives upgrades better than subclassing untyped internals.
Version pinning. With zero dependents and no public release history, pin the exact version ("jn-devops/properties": "1.2.3") — not ^1.0 — until you've audited how the package handles upgrades. A private package with no CI badge is a private package with no upgrade contract.
Test the package, not just your code. Wrap one happy-path test that exercises the package's own create→retrieve flow. If a future release breaks a migration or column name, that single test catches it far earlier than production.
How can I help you explore Laravel packages today?