Mise Laravel Package

Technical Evaluation

Architecture fit

Mise is a developer-tooling package, not an application dependency. It installs as a dev-only Composer requirement (tighten/mise --dev) and runs from the vendor bin as a CLI that executes JSON-defined recipes — ordered steps that copy stubs, prompt for variables, run shell/artisan commands, and wire in packages. That means it has zero production surface area: no service provider, no config merge, no runtime code path, no autoload pollution in deployed artifacts. Architecturally it sits alongside laravel new, Composer scripts, and Pint/Pest config generation in the "how do we get a new repo to a known-good state" layer.

For a team that stands up multiple Laravel services with shared conventions (auth scaffolding, CI files, static analysis config, Docker/compose, house naming), this is a legitimate fit. For a single product with one long-lived codebase, it solves a problem you mostly do not have after week one.

Integration feasibility (feasibility summary)

High. Adoption is a dev-dependency plus a recipes directory in a template or shared repo. No infra, no migrations, no secrets, no data model. A single engineer can have a working recipe in a day. The real work is not integration — it is the content authoring and the ongoing curation of steps as Laravel majors move.

Technical risk

• Abandonment / bus factor. A Tighten-owned OSS utility with negligible external adoption (near-zero dependents) is a single-maintainer risk. Recipes are executable shell semantics; if the tool stalls, your recipes rot silently rather than failing loudly.
• Recipe drift against framework upgrades. Laravel starter kits and installer behavior change between majors. Every recipe becomes a small compatibility surface you own; nobody upstream is testing your recipe.
• Non-idempotent execution. Recipes are step sequences, not transactions. A failure mid-run leaves a partially scaffolded tree — worst case is a repo that looks initialized but is missing CI or auth glue.
• Naming collision. "mise" is now strongly associated with the unrelated jdx/mise dev-tool manager. Expect confused searches, duplicate install instructions, and degraded supportability for anyone onboarding.
• Arbitrary command execution. Recipes invoke shell commands; a shared/internal recipe registry is effectively a code-execution channel into every engineer's machine. Needs review discipline.

Key questions

1. Who is the named owner of each recipe, and what is the review policy for a step that runs a shell command?
2. How many projects per quarter do we scaffold, and what is the measured cost of the current approach — this is the entire business case.
3. Does a recipe buy anything that a checked-in starter template repo plus Composer scripts does not? Templates give cleaner diffs and no new tool to maintain.
4. What is our exit condition — at what point do we fork, vendor, or replace with official Laravel starter kits?
5. Is the license and maintenance cadence acceptable for a tool in an agency-standard build path?

Integration Approach

Stack fit

Fits cleanly with a Laravel 10/11/12 monorepo-or-multirepo setup using Composer, Pest, Pint, and GitHub Actions. Recipes live in a small dedicated repo (or a stubs/ directory of a starter template) and are versioned and tagged separately from application code. No conflict with the Laravel installer; mise is a post-laravel new finisher, not a replacement.

Migration path

Do not rip out existing scaffolding. Run mise in parallel on the next 2–3 greenfield projects: a human follows the existing documented process, and the recipe is authored to reproduce exactly that process. Diff the outputs. Only after two clean reproductions does the recipe become the documented path.

Compatibility

Pin the mise version in composer.json dev requirements and pin package versions inside recipe steps explicitly (e.g. pestphp/pest:^3), never latest. Treat each Laravel major as a recipe-breaking event on the calendar — schedule a recipe review within the first sprint after every framework upgrade. Guard interactive prompts so recipes can run with pre-supplied variables in non-TTY contexts.

Sequencing

1. Inventory the current scaffold checklist; identify the three highest-drift items (typically CI config, static analysis, auth scaffolding).
2. Author one recipe covering those three only. Ship it narrow.
3. Pilot with two engineers on one real project.
4. Add a composer check-recipe smoke task that scaffolds into a temp dir and asserts a clean git status + passing composer test on the output.
5. Expand coverage only where the smoke task passes.

Operational Impact

Maintenance

Ongoing cost is recipe curation, not tool maintenance — budget roughly a half-day per framework major plus ad-hoc edits when a package's install UX changes. If mise itself goes unmaintained we are unaffected until a PHP/Composer compatibility break, at which point the fork cost is small (it is a thin CLI) but the recipe port to a shell script or template repo is smaller. Plan for the recipes to outlive the tool.

Support

No vendor SLA, no paid support, community issues only, and a low-adoption codebase means most failures will be diagnosed by us. Internal support load is the recipe owner answering "the recipe failed at step 4" — mitigate with clear step output and a documented manual fallback that always stays current.

Scaling

Trivially horizontal: it is a local CLI, no shared service, no concurrency concerns. Scaling concern is organizational, not technical — the recipe set grows per tech-stack variant (API-only, Inertia, Livewire) and each variant is another artifact to keep green. Cap the number of supported variants deliberately.

Failure modes

• Interrupted run leaves a partially applied scaffold → enforce a clean-tree precondition and a mandatory git init && git commit baseline before the first step.
• Interactive prompt in CI or a headless environment hangs the run → require variable flags for any automated use.
• Upstream package install command changes and the step silently no-ops → the smoke task is the control, not code review.
• Recipe diverges from what the team actually does → drift is invisible unless the recipe is the documented path and someone runs it monthly.
• Naming confusion sends a new hire to jdx/mise → put the exact bin path in onboarding docs.

Ramp-up

A Laravel-fluent engineer is productive on mise in under an hour; the mental model is "scripted checklist with prompts." The real ramp is cultural: engineers must be willing to update the recipe when they improve a project by hand, otherwise the recipe set decays into fiction within two quarters. Treat recipe updates as part of the definition of done for scaffolding improvements.