- What is williarin/cook and how is it different from a Laravel recipe package?
- williarin/cook is a Composer plugin, not a Laravel package: it hooks into Composer's install and update lifecycle and applies declarative recipes shipped inside dependency packages, such as file copies, config edits and script injections. That makes it a framework-agnostic analogue of Symfony Flex recipes that can serve Laravel, Symfony or plain PHP equally. It does not model cooking ingredients or recipe data; it automates the manual install steps that package READMEs currently describe.
- How do I install williarin/cook in a Laravel project?
- Require the package with Composer and then explicitly allow it under config.allow-plugins in composer.json, since Composer 2.2 and later block plugins by default. In a Laravel estate that is a one-line governance decision per repository rather than a code change. Pin the plugin version and commit the lock file, because it executes code at install time.
- What can a cook recipe actually do to my application?
- Recipes are declarative and shipped inside dependency packages; they can copy files, edit configuration, inject scripts and set environment keys. The evaluation notes they earn their place where Laravel's extra.laravel discovery and vendor:publish do not reach: env vars, files outside config/, multi-file scaffolds and conditional logic. The exact recipe schema, and whether dry-run or diff output exists, is one of the open questions to verify against the source before adopting.
- Is williarin/cook safe to run in production builds?
- Treat it as a supply-chain review obligation rather than a technicality. It turns installing a dependency into a dependency writing files into your project, so every recipe and every upgraded package version needs review. Pin the plugin version, avoid floating constraints and keep a documented install path that bypasses the plugin entirely.
- Are williarin/cook recipes idempotent, and is there a dry-run or rollback?
- Idempotency is not confirmed by the available evaluation and is listed as a key question: ask whether recipes are guaranteed idempotent, whether dry-run or diff output is supported, and whether partial failures roll back. Non-idempotent recipes produce dirty working trees, which becomes painful fast. Pilot on one internal package and diff the result against a hand-installed application.
- How does williarin/cook handle conflicts when two packages edit the same file?
- Ordering ambiguity when multiple recipes touch the same file, such as two packages editing config/app.php, is a flagged risk. Confirm how conflicts and existing file content are detected or merged before scaling to many packages. Restricting recipes to additive, narrowly scoped changes reduces the blast radius considerably.
- Does it replace Laravel package auto-discovery and vendor:publish?
- No, they are complementary rather than duplicative. Laravel's extra.laravel discovery and vendor:publish already cover provider registration and config publishing, so recipes should stay additive and focus on env keys, non-config files and multi-file scaffolds. Confirm behaviour under existing discovery during the pilot so install steps are not applied twice.
- What happens with --no-plugins or --no-scripts in CI and production builds?
- Because the plugin only fires on Composer hooks, --no-plugins and --no-scripts builds skip recipe execution entirely, which can cause silent divergence between CI or production and local installs. Document a --no-plugins path as the escape hatch and verify that both paths converge on the same application state. Add the expected recipe effects to your deployment checks.
- Does williarin/cook work with Symfony Flex or on non-Laravel projects?
- It is a Composer plugin, so nothing ties it to Laravel; it can serve Symfony or plain PHP projects. If any part of your estate uses Symfony Flex, confirm there is no collision, since both apply install-time recipe logic. Also check the PHP and Composer version floor against the oldest application you support.
- Is williarin/cook actively maintained, and should I use it instead of README install instructions?
- The project is small, around 25 stars, with what appears to be a single-maintainer bus factor and a very recent release history, so treat it as a dependency you may need to own. It fits best if you publish internal Laravel packages consumed by many first-party apps and are tired of hand-maintained install instructions drifting from reality; it is a weaker fit for a single application consuming public packages that ship no recipes. Start with a two-week pilot on one low-traffic internal package, with a written diff review against a hand-installed app.