v0.4.0

Rename a feature without the busywork

Iterating on a feature often means renaming it: Widget turns out to be a Gadget, or it belongs in another module. mod:rename renames or moves a whole cluster generated by one of your scaffold recipes in one step: every member, every PHP reference, and the frontend pages and imports that point at it.

php artisan mod:rename Inventory:Widget Inventory:Gadget --scaffold=crud   # crud: your own recipe

It shows the full plan first and asks before writing. The result is staged in git, never committed, so you review git diff --staged and commit yourself. If anything goes wrong it restores everything, and mod:rename --recover handles an interrupted run.

0.4 also publishes a supported API for packages built on mod, such as the upcoming Laravel-DDD 4.

Added

• mod:rename renames or moves a cluster generated by one of your scaffold recipes: mod:rename Inventory:Widget Inventory:Gadget --scaffold=crud. It plans every member's new path from the recipe and the layout; parts you grew later are included when you list them (--part=tab:Stock).
• PHP references are updated across the app with PHP's own tokenizer: namespaces, class names, imports, ::class, types, attributes and static calls, plus literal page and view names in Inertia::render() and view().
• Frontend references are updated with the app's own installed parsers (Babel for JS/TS, Vue's compiler): page names, @modules and @/ imports, relative imports and Blade view names and component tags. Anything computed, or any file it can't parse, goes on a review checklist with file and line; nothing is installed.
• Route names, URIs, translation and config keys and other strings that mention the old name are listed for review, never changed.
• When a rename changes a model's default table, --table-migration (or a prompt) adds a reversible migration that renames the table. Existing migrations and the database are never touched.
• A rename shows its plan and asks before writing (default No; --yes --no-interaction skips). The result is staged in git, never committed. It refuses on a dirty tree, an existing destination or a likely member it can't account for.
• A journal restores everything if a rename fails. After an interrupted run, mod:rename --recover finishes or rolls back (inspect with --recover --dry-run --json) without losing edits made meanwhile.
• --dry-run --json shows the full rename plan, and Laravel Boost's mod-plan tool can preview it.
• A supported API for packages built on mod: an independent copy of a built-in layout, place() and locate() on a compiled layout, host-owned discovery, a migration command that accepts Laravel's own migration creator, and a small set of documented generator hooks. A published-API snapshot keeps it stable.

Fixed

• Generators that use Laravel's native collision handling now create repeated migrations with the next timestamp, as make:migration does, instead of overwriting the first.

---

What's Changed

• Run Pint without Docker in the style workflow by @jaspertey in #41
• Publish a stable API for packages built on mod by @jaspertey in #40
• Plan renames of scaffolded clusters with mod:rename by @jaspertey in #42
• Keep Laravel's timestamps for migrations that use native collision handling by @jaspertey in #43
• Offer a reversible table migration when a rename changes a model's table by @jaspertey in #44
• Find frontend references for renames with the app's own parsers by @jaspertey in #45
• Rewrite PHP references when planning a rename by @jaspertey in #46
• Apply renames as staged git changes, with recovery by @jaspertey in #47
• Document renames and the API for packages built on mod by @jaspertey in #48

Full Changelog: v0.3.1...v0.4.0