PHPackages                             noxsii/laravel-after-migration - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Database & ORM](/categories/database)
4. /
5. noxsii/laravel-after-migration

ActiveLibrary[Database & ORM](/categories/database)

noxsii/laravel-after-migration
==============================

Run one-time hooks after a migration has been executed.

v0.2.0(3mo ago)11MITPHPPHP ^8.4CI passing

Since Mar 5Pushed 3mo agoCompare

[ Source](https://github.com/noxsii/laravel-after-migration)[ Packagist](https://packagist.org/packages/noxsii/laravel-after-migration)[ Docs](https://github.com/noxsii/laravel-after-migration)[ RSS](/packages/noxsii-laravel-after-migration/feed)WikiDiscussions main Synced 3w ago

READMEChangelog (2)Dependencies (6)Versions (3)Used By (0)

noxsii/laravel-after-migration
==============================

[](#noxsiilaravel-after-migration)

Run **one-time** post-migration hooks **after** a migration has been executed — without putting data updates, job dispatching, or “one-off scripts” inside your migrations.

> **Goal:** Keep migrations *schema-only* and move any non-schema work into dedicated, testable classes.

---

Why this package exists
-----------------------

[](#why-this-package-exists)

Laravel migrations are great for **schema changes**.
But in real projects you often see migrations doing things like:

- Updating existing rows (backfills)
- Dispatching jobs
- Calling external services
- Rebuilding caches / search indexes
- Moving data between columns

That’s a problem:

- **Migrations should be deterministic** and safe to run in any environment.
- **Data mutations inside migrations** are hard to test, hard to retry, and often slow.
- “One-time” logic becomes scattered across migration files and is easy to re-run by accident.

This package gives you a clean alternative:

✅ Write schema migrations normally
✅ Define a post-migration hook class
✅ Laravel runs the hook **exactly once** after the migration is executed
✅ Hook runs **after** the migration was recorded as executed
✅ Hook is a normal class: testable, DI-friendly, and readable

---

How it works
------------

[](#how-it-works)

- The package listens to Laravel’s `MigrationEnded` event.
- If the migration implements `AfterMigrationHook`, the package will:
    1. Resolve the **migration file name** via reflection (e.g. `2026_01_01_000001_create_widgets_table`)
    2. Run your hook
    3. Persist the run in `after_migration_runs`
- A unique constraint ensures the hook is executed **once per migration file + hook class**.

---

Installation
------------

[](#installation)

```
composer require noxsii/laravel-after-migration
```

Publish the package migration:

```
php artisan vendor:publish --tag=after-migration-migrations
php artisan migrate
```

(Optional) publish config:

```
php artisan vendor:publish --tag=after-migration-config
```

---

Usage
-----

[](#usage)

### 1) Create a hook class

[](#1-create-a-hook-class)

A hook is a simple class implementing `AfterMigrationJob`.

```