- What is tightenco/mise used for in a Laravel project?
- Mise is a dev-only Laravel package from Tighten for installing project recipes. A recipe is a JSON-defined sequence of steps that can copy stubs, prompt for variables, run shell or Artisan commands, and wire in packages. Teams use it to bring new or existing Laravel apps to a consistent, known-good setup.
- How do I install Mise in a Laravel application?
- Install it as a dev dependency with composer require tighten/mise --dev. It runs from the vendor bin as a CLI and does not register a service provider or merge config. You then author or point it at a recipes directory in a template or shared repo.
- Does Mise work with Laravel 10, 11, and 12?
- Mise fits Laravel 10, 11, and 12 workflows, but each recipe is its own compatibility surface. Laravel starter kits and installer behavior change between majors, so validate recipes per major and pin package versions inside steps. Treat a Laravel major upgrade as a recipe-review event rather than assuming recipes still work.
- Do I need to add Mise to production dependencies?
- No. Mise is intended as a dev-only Composer requirement and has zero production surface area. It adds no service provider, runtime code path, or autoload pollution to deployed artifacts. Keep it in require-dev and out of production installs.
- How are Mise recipes defined and configured?
- Recipes are JSON documents containing ordered steps. Steps can copy stub files, prompt for variables, run shell or Artisan commands, and add or configure packages. They live in a recipes directory in a template or shared repo and should be versioned and tagged separately from application code.
- Is Mise a replacement for laravel new or Laravel starter kits?
- No, Mise is not a replacement for laravel new or official Laravel starter kits. It sits alongside the installer, Composer scripts, and Pint or Pest config generation as a post-scaffold finisher. A checked-in starter template plus Composer scripts can often achieve similar results with cleaner diffs and no extra tool to maintain.
- What are the risks of using Mise recipes?
- The main risks are non-idempotent execution, recipe drift, and maintenance ownership. Recipes are step sequences, not transactions, so a mid-run failure can leave a partially scaffolded repo that looks initialized but is missing CI or auth glue. Recipes also become a compatibility surface you own as Laravel majors move, and a stalled upstream tool can let recipes rot silently.
- Is tightenco/mise the same as jdx/mise?
- No. The Composer package tightenco/mise is unrelated to the jdx/mise dev-tool manager. The name collision causes confused searches and duplicate install instructions, so be explicit in internal docs that you mean the Tighten Laravel recipe tool. Expect some onboarding and supportability friction because of the shared name.
- How should teams review Mise recipes that run shell commands?
- Treat a shared recipe registry as a code-execution channel into every engineer's machine. Assign a named owner for each recipe and define a review policy for steps that run shell commands. Pin the Mise version in composer.json and pin package versions inside recipe steps explicitly instead of using latest.
- How should a team test and adopt Mise safely?
- Run Mise in parallel on the next two or three greenfield projects while a human follows the existing documented process. Author the recipe to reproduce that process exactly, then diff the outputs. Only make the recipe the documented path after two clean reproductions, and decide in advance when to fork, vendor, or replace it with official Laravel starter kits.