Parametertouch Bundle Laravel Package

Getting Started

Install via Composer and register the bundle in your kernel:

composer require netgusto/parametertouch-bundle

// app/AppKernel.php (Symfony 2/3) or config/bundles.php (Symfony 4+)
$bundles = [
    // ...
    new Netgusto\ParameterTouchBundle\NetgustoParameterTouchBundle(),
];

First place to look: the bundle's DependencyInjection/ directory and its composer.json — the bundle wires into Composer's script/post-install events to touch() a set of files. The first use case is deliberately narrow: you want Symfony's container cache to rebuild automatically after composer install/composer update without a manual cache:clear. The bundle touches files (typically the kernel, config.yml, or a sentinel file) so that Symfony's timestamp-based cache invalidation fires on the next request.

If you've ever deployed, run composer install, and then had users hit a stale container (missing new service, wrong env var, old routes) until someone ran app/console cache:clear — this bundle is a blunt fix for exactly that.

Implementation Patterns

Post-install cache busting. The canonical pattern is to touch a kernel-level file so Symfony's Kernel::initializeContainer() sees a newer mtime than the cached container and rebuilds. Typical target: app/AppKernel.php or src/Kernel.php.

Composer script integration. Wire the bundle's behaviour into composer.json scripts so it runs consistently in CI and on deploy:

"scripts": {
    "post-install-cmd": [
        "@php bin/console cache:clear --env=prod --no-warmup"
    ],
    "post-update-cmd": [
        "@php bin/console cache:clear --env=prod --no-warmup"
    ]
}

The bundle effectively automates what this snippet does — use whichever fits your deploy pipeline.

Multi-env deployments. If you deploy without the --no-dev step or with shared caches across envs, be explicit about which files get touched per environment. A single sentinel file (e.g. var/cache/.build-stamp) that both the deployer and the bundle agree on is cleaner than touching PHP source.

Integration with deploy tooling (Capistrano, Deployer, Envoyer). Prefer running the touch as part of the release step rather than relying on the Composer event, because Composer's own working directory when it fires the script is the project root — make sure relative paths resolve there.

Gotchas and Tips

• The package is effectively unmaintained (0 stars, 0 dependents). Treat it as a shortcut, not a dependency to commit to long-term. The equivalent one-liner — touch src/Kernel.php or bin/console cache:clear — is more robust and does not add a bundle you must register in AppKernel.
• Inherited Composer event ordering. post-install-cmd/post-update-cmd fire after autoloading is dumped but before your app's own scripts that follow them. If the bundle touches a file the container depends on, the next command in the same Composer run will rebuild the cache once — you can end up doing the work twice.
• Permissions. touch() uses the process user. On servers where www-data reads and the deploy user writes, touched files can end up root-owned or with wrong perms, silently blocking cache rebuilds. Check ls -l var/cache and stat the touched file after a deploy.
• Debugging silent no-ops. If the cache still isn't invalidated, confirm the file the bundle touches is actually inside what Kernel::registerContainerConfiguration() watches — a file in vendor/ will not help. debug:container --env=prod (once the cache is rebuilt) and stat -c %y on the kernel file are the fastest checks.
• Config quirks. Because the bundle hooks into Composer rather than runtime, its "configuration" lives in composer.json scripts, not config.yml. Do not expect a bundle config key — none exists.
• Extension points. If you must keep it, wrap the touch target list behind your own Composer script and use the bundle only as an opt-in flag (e.g. only in require-dev). That way, abandoning the bundle later is a one-line change.
• Better alternatives. For day-to-day Symfony work, bin/console cache:clear in your deploy script, or setting a cache dir keyed on the build (%kernel.cache_dir% overridden by COMPOSER_INSTALL_TIMESTAMP) gives the same guarantee without depending on a zero-star bundle.