williarin/cook
Cook is a Laravel package for managing recipes: define ingredients, steps, and cooking details as Eloquent models, then query and display them in your app. It ships with migrations and models to get a recipe section running fast.
Architecture fit. williarin/cook is a Composer plugin, not a Laravel package. It hooks into Composer's install/update lifecycle and applies declarative "recipes" shipped inside dependency packages — file copies, config edits, script injections. That places it one layer below the framework: it can serve Laravel, Symfony, or plain PHP equally. For a Laravel estate, it is a framework-agnostic mechanism for automating the manual install steps that package READMEs currently describe: registering providers, publishing config, appending env keys, wiring routes. Architecturally it is a lighter, generic analogue of Symfony Flex recipes. The key architectural tension is that Laravel already has extra.laravel package discovery and vendor:publish, which cover a meaningful subset of what recipes would do. Recipes earn their place only where auto-discovery doesn't reach: env vars, files outside config/, multi-file scaffolds, and conditional logic.
Integration feasibility. Feasible and low-effort to trial. Composer 2.2+ requires explicit allow-plugins entries, so adoption is a one-line governance decision per repository rather than a code change. The real cost is authoring and reviewing recipes, not installing the plugin. A pilot on one internal package is a day's work.
Technical risk. Install-time code execution is a privileged surface, and this package turns "install a dependency" into "dependency writes files into my project." That is a supply-chain review obligation, not a technicality. Secondary risks: non-idempotent recipes producing dirty working trees, ordering ambiguity when multiple recipes touch the same file (e.g. two packages editing config/app.php), silent divergence when --no-plugins is used in CI or production builds, and overlap or conflict with Symfony Flex if any part of the estate uses it. The project is 25 stars with what appears to be a single-maintainer bus factor and a very recent release history; treat it as a dependency you may need to own.
Key questions. What is the recipe schema, and does it support dry-run/diff output? Are recipes guaranteed idempotent, and is there a rollback on partial failure? How are conflicts between recipes and existing files detected or merged? Which Composer hooks fire, and what happens under --no-plugins or --no-scripts? Does it coexist with Flex? Is there any integrity/signature check on recipe content? What is the maintainer's stated support window and backward-compatibility policy? Does it work for both require and require-dev packages?
Stack fit. Best fit is an organisation that publishes internal Laravel packages consumed by many first-party applications and is tired of hand-maintained install instructions drifting from reality. Weaker fit for a single application consuming public packages, where the plugin would have to be adopted by upstream maintainers you don't control — recipes only help if packages ship them.
Migration path. Do not retrofit existing packages. Pick one new or low-traffic internal package, add williarin/cook to allow-plugins, ship a recipe that reproduces its current manual install steps, and run it against a scratch application. Diff the result against a hand-installed application; any discrepancy is a recipe bug or a documentation bug you have now surfaced. Keep a --no-plugins install path documented as the escape hatch and verify both paths converge.
Compatibility. Confirm PHP and Composer version floor against the estate's oldest supported application. Confirm no collision with Flex in any Symfony-adjacent repo, and confirm behaviour under Laravel's existing discovery so recipes are additive rather than duplicative. Pin the plugin version in composer.json and lock it; do not float a plugin with install-time write access.
Sequencing. (1) Pilot one package, two weeks, with a written diff review. (2) Draft a recipe style guide — idempotency, scoping to the host project, no destructive overwrites, one file per recipe concern. (3) Add CI that installs a fixture app with the plugin enabled and asserts the resulting tree matches a committed expectation, so recipe regressions fail the build rather than a developer's laptop. (4) Roll out to the internal package fleet package by package. (5) Only then consider public packages, where you cannot enforce adoption.
Maintenance. The plugin itself is small and slow-moving, which is good, but it is a single-maintainer project at 25 stars. Budget for the possibility of forking or vendoring it; the MIT licence makes that viable and the surface area is small enough that a fork is a realistic contingency rather than a rewrite. The larger maintenance load is the recipe corpus: every recipe is code that must be kept correct against N supported versions of the host application, and that cost compounds with the number of packages and the number of application templates.
Support. Recipes introduce a concept developers have not seen. The failure mode is opaque — a broken install surfaces as a Composer error or a subtly wrong config file, not as a stack trace in application code. Expect support load concentrated at onboarding and at Composer major-version upgrades. Mitigate with a short internal doc, a recipe template, and a rule that every recipe failure message names the package and file involved.
Scaling. Execution cost is negligible; N packages with recipes is still sub-second work. The scaling problem is combinatorial conflict: as recipe count grows, the probability that two recipes touch the same file rises, and resolution is order-dependent and implicit. Cap the blast radius by convention — recipes own narrowly scoped files, and shared files like config/app.php are handled by exactly one recipe or not at all.
Failure modes. Partial application leaving a dirty working tree with no rollback; overwrite of local customisations on re-install or update; recipes firing during an unrelated composer update and changing files the developer did not intend to touch; silent divergence when CI or production runs with --no-plugins, producing an application that differs from every developer's machine; blocked plugin due to a missing allow-plugins entry causing confusing install failures for new team members; and upstream recipe changes arriving as a transitive effect of a routine dependency bump, which is the hardest to attribute during an incident. Each of these needs a documented detection and recovery step before rollout.
Ramp-up. Low for consumers — install, allow, done. Moderate for recipe authors — the schema is likely simple, but the discipline around idempotency, scoping, and conflict avoidance is not obvious and must be taught. Estimate one to two days for a senior engineer to become productive as a recipe author, plus half a day of governance and security review before the first production application adopts the plugin.
How can I help you explore Laravel packages today?