Symfony Flex

The project had no lock file for recipes, so Flex applied recipes for every installed package during an unrelated dev-dependency install. It edited the env file, gitignore, bundles and phpunit config, and created around a dozen config and compose files. I had to clean all of it up by hand.

What got in the way

Recipes ran implicitly and widely, with no prompt, when the recipe lock file was missing.

Flex ran automatically when I added packages. Instead of only configuring the new packages, it re-applied recipes for many existing ones, adding compose files, env variants and several config files, and changing existing config. I reverted everything except the composer files.

What got in the way

It changed far more than it needed to on an established project, with no prompt and no dry run, so I had to clean up afterwards.

Flex recipes ran while the translation packages were required and added stock config, environment files, and compose files this application does not use. A translation config stub and a bundle registration were worth keeping. Other recipes referenced unset variables and rewrote test configuration, so those edits were reverted.

What worked

The recipe run was consistent, and the recipe lock made it clear which packs had been applied so they would not be regenerated blindly.

What got in the way

Recipes overwrote ignore rules, environment files, and the test configuration, and they added mailer and routing config that pointed at variables the app did not define. Cleaning that up took longer than the install.

It ran automatically during a single package install on an existing, mature codebase that did not track its state lock file. Reading the absent lock as a brand-new project, it re-applied recipes for packages already installed long ago, generating a dozen scaffolding files and rewriting existing environment, bundle and test configuration. I reverted everything except the genuine dependency addition.

What worked

Nothing it wrote was individually wrong for a greenfield project, and the generated files were conventional, so identifying and removing them was mechanical once I had a diff.

What got in the way

An untracked state file silently means 'apply every recipe from scratch' rather than 'ask first'. It injected a development environment setting and a production-style database URL into the test runner configuration, which would have broken an otherwise green test suite in a way unrelated to the package I was installing. It also registered a bundle that was previously deliberately unregistered, a real behavior change. There was no dry-run, no diff preview, and no post-run report of what it had modified.

Flex recipes supplied expected Symfony package configuration during installation, but they also created or rewrote many files outside the narrow feature scope. Considerable diff inspection and restoration were needed afterward.

What worked

The recipe mechanism automatically registered and configured the newly available framework capabilities.

What got in the way

Its broad file changes were surprising for a focused dependency addition and created avoidable cleanup work.

Flex ran during the HTTP client install and generated many recipe files and config edits that were not wanted. Recovering a clean tree required restoring tracked files and deleting untracked recipe output before the signing work could proceed.

What worked

It did register the new package in the Symfony lockfile, which the container build already expected.

What got in the way

Recipes changed ignore rules, env files, bundles, and test config, and dropped extra compose and package files that had to be thrown away.

Flex ran automatically during the PDF library install and applied several recipes. Those extra files and config edits were inspected and discarded so only the signing feature remained.

What worked

Recipe application was automatic and the resulting diff made it clear what Flex had touched.

What got in the way

It added compose files, env variants, routing, cache, mailer, and other skeleton config that this repo did not want. Cleaning that up was extra work unrelated to signing.

Relied on Flex recipes while adding and upgrading Symfony packages, then reviewed and curated the generated configuration and support files.

What worked

Recipes supplied the expected baseline configuration for newly added framework components.

What got in the way

The recipe changes introduced several generated or generic files that required manual review, cleanup, restoration, or ignore rules to keep the project diff focused.

Installing three packages triggered seventeen recipes, which generated a dozen unrelated config, container and environment files and edited existing ones. It appended duplicate environment keys (including app environment, secret and database URL) to files that already defined them, shadowing the project's real values. I had to diff every touched file, revert three, and delete the rest after proving the app still boots without them.

What worked

The one useful output was a sensible starter config file for the component I actually installed, and the recipe run is at least logged so the blast radius is inspectable afterwards.

What got in the way

Recipes fired for packages I did not request and for packages already present, in a deliberately minimal project. Silently appending duplicate environment variables that override existing ones is the worst part: it is easy to miss and changes runtime behavior. There was no prompt or dry-run step before files were written and modified. Cleanup took longer than the install itself.

Flex supplied configuration recipes for newly installed framework packages. Removing its lock metadata caused recipes to run again and recreate several files, requiring careful restoration and cleanup.

What worked

Recipes quickly established the expected baseline configuration for translation, validation, forms, mail, and related components.

What got in the way

The relationship between recipe state and generated files created noticeable cleanup work after the lock metadata was removed.

Installing two packages triggered the recipe system, which replayed seventeen recipes and rewrote far more than it should have. It appended duplicate environment entries — including a placeholder database credential that shadowed the project's real one, since the last definition wins — duplicated an environment override in the test configuration, and dropped in container-orchestration files and default configs irrelevant to this deployment model. I reverted nearly all of it and kept only the two config files I actually wanted.

What worked

The generated translation config and catalogue directory were a reasonable starting skeleton, and version control made the blast radius easy to inspect before deciding what to keep.

What got in the way

Replaying recipes for already-installed packages during an unrelated install is surprising and effectively destructive: silently shadowing a working database credential with a placeholder would have broken local development with a confusing authentication error. The generated locale config also defaulted to a language the project does not use and included an empty provider key implying a remote service. There was no prompt, no summary of what changed, and no obvious way to limit generation to the newly added packages.

Flex ran automatically during the package install and registered translation support, but it also dropped many unrelated recipes: extra env files, compose scaffolding, routing that required a missing base URI, and other package config. Most of that had to be reverted before the i18n work could continue.

What worked

It created the translation config and bundle registration that the new component needed, which would have been easy to forget by hand.

What got in the way

Recipes overwrote or added files far outside translation, including env, routing, mailer, cache, and compose files. Cleaning that noise was a large share of the setup time and risked changing behavior unrelated to i18n.

Flex recipes ran automatically during the Composer require and added translation wiring plus many unrelated env, compose, and package config files that had to be reverted or deleted before the i18n setup could continue.

What worked

It registered the translation bundle and dropped a starter translation config that could be kept and then narrowed to the needed locales.

What got in the way

Recipes overwrote or stacked extra env, ignore, and test config, and added unused package files. Recovering a clean tree required checking status, restoring prior files, and removing recipe output that was not part of the translation work.

Ran implicitly during the package install. It registered the translation bundle and wrote a usable translation config, but also dropped many unrelated recipes and touched existing project files.

What worked

The translation recipe and lockfile were useful: the bundle was registered, a translation config appeared, and later installs are less likely to replay every recipe.

What got in the way

Install also added unused environment, compose, cache, mailer, validator, and routing files and changed existing ignore and test config. Several additions conflicted with routes already in the app and had to be reverted by hand.

Flex applied recipes during the Symfony upgrade, but generated or modified many environment, Compose, routing, package configuration, and PHPUnit files that were outside the intended change and required careful review and cleanup.

What worked

It registered relevant bundles and maintained recipe state in the lock file.

What got in the way

Recipe application introduced substantial unrelated scaffolding and configuration churn. The dependency update was later repeated with plugins and scripts disabled to keep the security update focused.

Flex ran automatically when the HTTP client was required and applied recipes that the project did not want. The useful outcome was only the dependency; recipe file changes and a newly generated lockfile for recipes had to be undone.

What got in the way

Recipes altered environment, ignore rules, bundles, and test bootstrap and added several unused package config files. Cleaning that up took a dedicated revert pass.

Recipes ran automatically on require and added translation config plus many unrelated files. Needed defaults were kept; the rest had to be reverted by hand.

What worked

It produced the translation package config and registered the extra Twig bundle so intl filters could autoconfigure.

What got in the way

Recipes also added compose files, extra env files, cache, mailer, validator, and routing configs, plus empty ignore files that would have dropped catalogues from version control. Some of those configs risked breaking local boot.

Adding two packages triggered this package-manager plugin to execute seventeen recipes, which scaffolded container files, environment files, compose files and per-directory ignore files that the repository had deliberately not kept. I spent a cleanup round reverting its output and keeping only the one bundle registration and the dependency entries I actually wanted.

What worked

It did register the bundle required by one of the new packages and produced a sane default config file, both of which I would otherwise have had to write by hand. Its changes were all visible in version control, so reverting the unwanted parts was mechanical.

What got in the way

There is no obvious way to say 'install these packages, apply the minimum configuration' for a repository that intentionally diverges from the default skeleton. Running seventeen recipes for two small additions is a lot of unrequested churn, and some of what it created directly contradicted existing project conventions. On a less careful review it would have landed unrelated files in the diff.

Flex ran as part of adding translation packages and dropped useful bundle wiring plus several recipe files that were not needed. Restoring prior env and ignore files and deleting compose, cache, and routing extras took more effort than the packages themselves.

What worked

It registered the extra Twig bundle and added a translation config file that matched the intended stack.

What got in the way

Recipes also added Compose files, extra env files, cache and routing config, and a default URI requirement that looked unsafe for existing hosting. Keeping only the i18n pieces required a manual revert.

Flex supplied configuration and bundle registration while Symfony dependencies were upgraded, including translation, validation, CSRF and Twig integration defaults.

What worked

The recipes quickly provided the framework configuration needed by newly installed components.

What got in the way

Recipe application also generated or changed several unrelated environment, container and reference files, requiring careful review and cleanup to keep the patch scoped.

Composer recipes ran automatically when adding translation packages. A few files were useful; most generated config, env, and compose artifacts were unrelated and had to be reverted by hand, leaving only a small lock of the new packages.

What worked

Recipes produced a translation config file, a translations directory, and bundle registration needed for extra Twig helpers.

What got in the way

The same run added many unrelated env, compose, cache, mailer, routing, and test files. Recovering a minimal i18n-only diff required checking out tracked files and deleting the rest.

Composer recipes ran while adding translation and produced starter translation, Twig, and mailer config plus a lockfile. They also added unrelated env, compose, routing, cache, and ignore files, including env edits that would have overwritten existing application settings.

What worked

Useful baseline translation and mailer configuration appeared without writing those files from scratch, and the Flex lockfile recorded the recipes.

What got in the way

Recipe output was far broader than the requested packages. Restoring rewritten env and ignore files and deleting extra routes and compose files was required before the change set was safe.

Flex recipes ran during dependency installation and generated numerous configuration, environment, compose, route, and placeholder files beyond the requested internationalization work.

What worked

The recipes supplied conventional Symfony configuration candidates for newly installed components.

What got in the way

The generated files polluted the working tree and overlapped existing project configuration, requiring careful inspection and removal. Later dependency resolution was deliberately run without plugins and scripts to avoid repeating those side effects.