Hot Reload Bundle Laravel Package

Product Decisions This Supports

Primary decision: build vs. buy for a developer-experience (DX) feature, not a product feature. This bundle solves one narrow problem: when a Symfony app runs under FrankenPHP in worker mode, the browser needs the FrankenPHP hot-reload client injected so that code changes trigger an automatic page reload. The bundle auto-injects that client only when FRANKENPHP_HOT_RELOAD is present. That is a convenience wrapper, not a capability.

Implications for a PM:

• Scope check first. It is a Symfony bundle, not a Laravel package. If the roadmap item that surfaced this is "improve Laravel dev experience," this package does not apply. If it is "evaluate FrankenPHP worker mode for our Symfony services," it is a legitimate (if minor) input.
• Treat as an enabler of a platform bet, not a feature bet. The real decision is "do we adopt FrankenPHP worker mode?" This bundle is a ~zero-cost accessory to that decision. Do not let a 0-star dependency drive a platform choice; let the platform choice decide whether this bundle is worth including.
• Roadmap impact: near-zero on its own, positive as a DX tax reduction. Value shows up as faster inner-loop feedback for engineers on FrankenPHP stacks — measured in reload friction and "why didn't my change show up" support pings, not in user-facing metrics.
• Use case fit is narrow and clear: local/Docker development environments where FRANKENPHP_HOT_RELOAD is set, and where you do not already have a reload path (e.g., a reverse proxy watcher, symfony server:watch, or a Vite/vite-symfony HMR setup handling the frontend side). If your frontend already has HMR via Vite, this covers only the PHP-side reload, which narrows the benefit further.
• Opportunity signal is 48.78 while overall score is ~19.7. Read that as: the underlying problem space (FrankenPHP DX) is interesting to the ecosystem, but this specific implementation has essentially no traction (0 stars, 0 dependents). That combination is the classic "small useful idea, no community validation" profile — a fork-and-own candidate rather than an adopt-and-depend candidate.
• Release date of 2026-10-13 is in the future relative to most evaluation windows. Confirm the actual published version and changelog before citing it in any planning doc; a future-dated release is either metadata noise or a scheduled/backdated tag, and either way it undercuts "actively maintained" as an adoption argument.
• Licensing and compliance are clean. MIT removes legal friction; the decision is purely technical risk tolerance.
• Build cost is low enough to make "buy" hard to justify. The functional surface is essentially a Twig include plus an environment check. An engineer can reproduce it in hours and keep it in-repo, which changes the calculus from "evaluate a dependency" to "decide whether to accept a dependency for something we could own outright."

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony, not Laravel (or the monolith is Symfony and you are not trying to force parity across frameworks).
• You are already committed to FrankenPHP in worker mode for local development, ideally in Docker Compose, and FRANKENPHP_HOT_RELOAD is a first-class env var in your dev setup.
• You want zero-config injection — i.e., you do not want every developer to remember to add a script tag or maintain a custom base template block.
• You are comfortable pinning an exact version and, in practice, vendoring or forking the code so a single-maintainer package cannot break your dev environment or introduce an unaudited include path.
• The bundle's PHP/Symfony constraints (PHP >=8.1 <8.6, Symfony 7.4/8.0/8.1 with broader ^6.0 || ^7.0 || ^8.0) are compatible with your matrix. Anything older than Symfony 6 is out of scope.

Look elsewhere — or just don't adopt — when:

• The project is Laravel. This is a Symfony bundle; there is no Laravel integration here.
• You are not on FrankenPHP, or you run it only in classic (non-worker) mode, where the hot-reload client has nothing to attach to.
• You need production behavior. This is a dev-affordance bundle; hot reload in production is a foot-gun, and you should verify the env-gating actually keeps it dark outside dev before trusting it.
• Your frontend reload needs are already solved by Vite HMR / vite-symfony, and PHP-side reload is not a felt pain. Adding a dependency to solve an unfelt problem is negative value.
• Your org requires maintainer-health thresholds — stars, dependents, release cadence, security policy, multiple maintainers. This package fails all of them (0 stars, 0 dependents, single-maintainer profile), and no amount of "it's only dev tooling" fully excuses a dependency review bypass if your policy is uniform.
• The total surface is small enough that an in-house Twig include is cheaper than the review, pinning, and upgrade-watching overhead of a third-party bundle.

Decision rule I would apply: treat this as an internal utility you happen to source from GitHub. Evaluate it as you would a code snippet, not as a vendor dependency — read the whole thing, pin it, and be prepared to own it.

How to Pitch It (Stakeholders)

To executives (30 seconds): "This is a small, free, MIT-licensed helper for teams using FrankenPHP, a newer high-performance PHP runtime. It removes a repetitive setup step in developers' local environments, so code changes show up faster. It carries no licensing cost and no production risk, because it only affects development machines. The honest framing: it is a minor convenience, not a capability we lack — our real decision is whether to standardize on FrankenPHP, and this is a cheap accessory to that decision, not a reason to make it. It has no community adoption, so I recommend we either skip it or copy the few lines of logic into our own codebase rather than take on a dependency."

To engineering leads:

• What it does: injects the FrankenPHP hot-reload client asset when FRANKENPHP_HOT_RELOAD is available; nothing more.
• Why we might want it: removes per-project boilerplate and makes worker-mode reload work by default in Docker dev setups — a real inner-loop win for teams already on FrankenPHP.
• Why we might not: the entire behavior is a conditional asset include. We can own it in-repo in an afternoon, which removes the supply-chain question entirely and eliminates upgrade-watching for a dependency that has 0 stars and 0 dependents.
• Risk posture if we do adopt: pin an exact version, vendor or fork it, confirm the env-var gating cannot activate outside dev, and verify the stated compatibility range against our actual PHP/Symfony matrix before merging.
• Recommendation: prototype it in one service to validate the DX gain; if the gain is real, reimplement minimally in-house rather than depending on the upstream package. If the gain is not measurable, drop it and move on — this should not consume more than a day of evaluation.