Parametertouch Bundle Laravel Package

Product Decisions This Supports

• Deploy-time cache invalidation strategy. The package's only job — touching files during composer install / composer update — exists to signal to a framework (Symfony) that configuration or cache artifacts are stale. A PM decision here is really "how do we guarantee cache freshness after dependency changes," not "which bundle do we install."
• Build vs. buy vs. configure. This is a five-line composer.json script in modern tooling. The decision it informs is whether the team standardizes cache-busting as a documented Composer hook, a CI/CD step, or a framework-native command (cache:clear, artisan optimize:clear).
• Roadmap: legacy Symfony surface area. Relevant only if the roadmap includes maintaining or migrating a Symfony 2/3-era application. It is a migration-scope input, not a new-feature input.
• Use cases it legitimately covers: post-install parameter/config file refresh in older Symfony apps; triggering asset or cache rebuilds where no other hook fires; environments where the deploy pipeline cannot run arbitrary shell commands but Composer can.
• Vendor and supply-chain review. Zero stars, zero dependents, zero dependents' dependents — the decision it most directly supports is "do not add this as a dependency," and instead capture the behavior as first-party configuration.

When to Consider This Package

Consider it only when all of the following hold:

• The application is a Symfony project (this is a bundle — it does not apply to Laravel out of the box), and specifically an older one predating Symfony Flex recipes and cache:clear automation.
• You genuinely cannot add a post-install-cmd / post-update-cmd script to composer.json — e.g., the manifest is managed by another team or generated.
• The only required behavior is "touch these paths after Composer runs," with no versioning, no config, and no reporting.
• You have accepted the risk of an unmaintained, effectively unknown dependency and are prepared to vendor or fork it.

Look elsewhere when:

• You are on Laravel. Use php artisan optimize:clear, package discovery, and Composer script hooks directly. A Symfony bundle is the wrong shape and would require the Symfony service container.
• You are on modern Symfony. Composer scripts plus bin/console cache:clear in the deploy pipeline cover this without a dependency.
• You need real cache-busting. Cache tags, versioned asset manifests, or content-hashed filenames solve this properly; file touch is a blunt instrument that also defeats incremental builds.
• Supply-chain hygiene matters (it does). Zero stars, zero dependents, and no maintainer signal is a red flag for anything entering production.
• You need it to work across Composer 2, PHP 8, and current Symfony. No evidence of compatibility; assume breakage.

How to Pitch It (Stakeholders)

To executives: We evaluated netgusto/parametertouch-bundle, a small Symfony add-on that touches files after Composer installs or updates so the framework rebuilds its cache. My recommendation is not to adopt it. Its entire function can be reproduced with a few lines in our own composer.json, it has no meaningful adoption (zero stars, zero dependent projects), and it appears unmaintained. Adding it would introduce a third-party dependency, a supply-chain review, and a future migration cost in exchange for behavior we already control. Our recommendation is a one-time configuration change owned by engineering, not a new vendor relationship — lower risk, zero cost, and no lock-in.

To engineering: This is a Symfony bundle, so it is only relevant if we have a legacy Symfony service in scope; on Laravel it does not apply. The behavior is a post-install-cmd / post-update-cmd hook touching the relevant cache or parameters file, or — preferably — invoking the framework's own cache-clear command in the deploy pipeline. touch-based invalidation also undermines incremental builds, so if we adopt this pattern at all, we should scope it tightly to the specific cache paths that need it and document why. Please treat this as a rejected dependency and a two-hour configuration task instead.