Laravel Schema Extend Laravel Package

Getting Started

Install via Composer:

composer require zedisdog/laravel-schema-extend --dev

The package is a set of Blueprint macros that are registered through its service provider. On Laravel 5.5+ the provider is auto-discovered; on older versions add Zedisdog\LaravelSchemaExtend\LaravelSchemaExtendServiceProvider::class to config/app.php. Confirm it is registered before running migrations — the macros are only available to Schema::create/Schema::table closures once the provider has booted.

Where to look first:

1. The package src/ directory for the Blueprint::macro(...) calls — these tell you the exact method name, default column name, and whether a foreign key/index is attached by default.
2. vendor/zedisdog/laravel-schema-extend/README.md for the canonical method list.
3. Laravel's own Illuminate\Database\Schema\Blueprint to see what the package is wrapping (usually unsignedBigInteger + foreign).

First use case — collapse the common "foreign key to users" boilerplate:

Schema::create('posts', function (Blueprint $table) {
    $table->increments('id');
    $table->user();          // user_id + FK to users.id
    $table->string('title');
    $table->timestamps();
});

instead of:

$table->unsignedBigInteger('user_id');
$table->foreign('user_id')->references('id')->on('users');

That is the day-to-day value: shorter migrations for convention-driven foreign keys.

Implementation Patterns

Convention-based foreign keys. Use the package's shorthand for columns that always follow the same shape (owner, author, post, category). Reserve native foreignId()->constrained() for anything that needs custom table/column names or onDelete behavior — mixing both is fine as long as your team knows the rule.

Audit/timestamp helpers. If the package exposes timestampsTz-style helpers or soft-delete variants, standardize on them in a shared base migration or a trait so timezone columns are consistent across tables. This is where the package saves the most repeated code.

Nullable/soft relationships. For optional ownership, combine with nullable() (if the macro returns the column definition) or chain the package's nullable variant. Test the down() path — a nullable FK is dropped cleanly with the column on most drivers, but explicit dropForeign is safer cross-database.

Team consistency over cleverness. The package is most useful when it encodes house conventions: e.g., "every *_id FK to a standard table uses the shorthand." Write that into your migration style guide, otherwise developers will mix macro and native syntax and reviewers will not know which is authoritative.

Integration with models/factories. Nothing changes at the Eloquent layer — these are still normal integer columns. Keep belongsTo definitions and factory references aligned with whatever column name the macro produces (usually <singular>_id), because the package will silently use its own default if you omit the argument.

Rollback ordering. When a migration creates several shorthand FKs, dropping the table is usually enough, but if you split tables across migrations, drop child FKs (or the child table) before the parent table. php artisan migrate:rollback --step=1 per batch makes this predictable.

Extending the pattern. If your schema has a recurring shape the package does not cover, define your own macro in a service provider:

Blueprint::macro('tenant', function () {
    return $this->unsignedBigInteger('tenant_id')->index();
});

This is the intended extension point — keep custom macros in one provider so they load for every migration.

Gotchas and Tips

• Maintenance risk. The package has a small star count and a WTFPL license (no warranty, effectively unmaintained). Pin the version in composer.json and review it before upgrading Laravel. On modern Laravel (8+), foreignId('user_id')->constrained() covers most of what this package does, so consider it a stopgap rather than a long-term dependency.
• Not a replacement for Laravel schema features. It supplements Blueprint; it does not change the query builder, model casts, or anything at runtime. Do not expect $table->user() to be understood by other tooling (IDE stubs, schema dumpers) without the provider loaded.
• Macro registration timing. In tests using RefreshDatabase, the provider must be registered in the test environment too. If migrations fail with "method does not exist," the provider is not booted — check php artisan about / config/app.php before debugging the migration itself.
• Column naming assumptions. The macro picks a default column name (e.g. user_id). If you pass a custom name, verify the generated foreign key and index names do not exceed your database's identifier limit (MySQL: 64 chars). Long table names plus default FK naming is a common cause of "identifier name too long" errors.
• Driver differences. Foreign key and comment behavior differs between MySQL, PostgreSQL, and SQLite. SQLite in particular does not enforce FKs unless enabled, so a migration that "works" locally can still hide constraint problems in CI. Run migrations against your production driver at least once.
• Index/FK collisions. If you already added ->index() on the column and the macro adds its own index, you can hit duplicate index errors. Read the macro source for exactly which index/constraint it adds.
• Debugging. Use php artisan migrate --pretend to see the SQL the macros generate, and Schema::getColumnListing('posts') in tinker to confirm columns and naming. DB::getQueryLog() around the migration will not show schema DDL reliably on all drivers.
• Downgrade/rollback quirks. If the package attaches a named foreign key, dropping the column may leave the constraint on some drivers. Prefer $table->dropForeign(['user_id']) explicitly in down() when in doubt.
• Do not mix mental models. Treat this package as syntax sugar only. If you find yourself reaching for it to do something Laravel cannot already express, you are probably fighting the framework — use a raw DB::statement or native blueprint methods instead.