Laravel Dynamic Column Laravel Package

Getting Started

halalsoft/laravel-dynamic-column is a small, early-stage package (still on 0.1.x) for attaching columns/attributes to Eloquent models at runtime rather than through a schema migration. The v0.1.3 release is a single bug fix (issue #6) — no API additions, no deprecations — so treat this as a stability patch rather than a feature release.

First steps:

1. composer require halalsoft/laravel-dynamic-column:^0.1.3 — pin the minor version, the public API is not yet stable.
2. Publish and inspect the package assets: php artisan vendor:publish --provider="HalalSoft\DynamicColumn\...ServiceProvider" (config and any migration). Read the published config before running anything — the defaults tell you more about the intended storage model than the README does.
3. Run the migration, then apply the package trait to one model in a scratch branch.
4. Read src/ first (it is small), then the issue tracker. With a package this young, the tests and the GitHub issues are the real documentation.

Best first use case: a model that needs user-defined or per-tenant extra fields (custom profile attributes, product metadata) without a migration for every new field. Start with one model and one column definition before generalising.

Implementation Patterns

• Trait on the model. The typical integration is use DynamicColumn; on the Eloquent model plus a definition of which columns are dynamic. Keep that definition in one place (a config array or a dedicated service) so it can be cached and validated centrally.
• Definition-driven, not string-driven. Wrap column creation in a small value object or enum (DynamicColumn::make('vat_number')->string()->nullable()) rather than scattering raw strings through controllers. This is what makes the package survive the next 0.1.x bump.
• Admin/UI-driven custom fields. The natural fit is a settings screen where an admin adds a field, and the package materialises it. Pair this with a form-builder that reads the same definition source.
• Casting and validation. Register casts and validation rules alongside the column definition so the model, the request layer and the API resource all agree on types. Don't rely on the package to cast for you.
• Per-tenant schema. If you're using this for tenant customisation, define columns per tenant and cache the resolved set per tenant ID; recomputing definitions on every request is where this pattern usually gets slow.
• Testing seam. Wrap the package's public calls behind your own facade or repository so tests (and a future replacement) don't depend on a 0.1.x API directly.

Gotchas and Tips

• Version pinning is not optional. 0.1.x means breaking changes are legitimate on a patch bump until 1.0. Pin exactly (0.1.3) in composer.json and read each release note before upgrading.
• v0.1.3 is a bug fix for issue #6. Check the issue before upgrading — if you have a workaround in place for that bug, remove it after upgrading, or you'll double-apply the fix. Run your own test suite; a patch release this small rarely gets broad regression coverage.
• Schema changes at runtime are the risk. If the package alters real tables, it can collide with queued jobs, read replicas and long-running workers that cached the old schema. Prefer running any materialisation step in a deploy hook or a queued job, not mid-request.
• Query performance. Dynamic attributes stored as JSON or added columns behave very differently under WHERE and ORDER BY. Verify index support on your engine before building list screens on top of it.
• Driver differences. MySQL, Postgres and SQLite diverge on altering tables and on JSON querying. Test on the engine you deploy to; SQLite in CI will not catch everything.
• Mass assignment and serialisation. New dynamic attributes won't be in $fillable or $hidden automatically. Decide explicitly whether they're fillable and whether they appear in toArray()/API resources.
• Migration ordering. Any package migration must run before your own schema changes that reference dynamic columns; check the timestamp.
• Debugging. When a column "doesn't exist", check the resolved definition cache first, then the actual schema, then the model's trait boot. In that order — the cache is the usual culprit.
• Extension point. If you need behaviour the package doesn't offer yet, prefer composing around it (your own definition registry + a thin adapter) over forking. At 0.1.x, forks are cheap but merge cost is high.