Symfony Vite Bundle Laravel Package

Product Decisions This Supports

• Frontend tooling standardization (PHP-rendered apps). This bundle is the glue layer that lets a Symfony backend consume a Vite build: reading the manifest, injecting correct <script>/<link> tags, proxying the dev server for HMR, and handling versioned assets in production. The decision it informs is "do we adopt Vite as our frontend build tool across our PHP services, and what's the integration cost?" — not "should we use this specific package?"
• Build vs. buy vs. borrow. Integration code of this kind is typically 200–400 lines (manifest parsing, entrypoint resolution, dev/prod mode switching, CSP nonce support). The realistic options are: (a) adopt a community bundle, (b) write and own ~300 lines in-house, (c) skip the problem entirely with a first-party path. This package is best framed as a reference implementation for option (b), not a vendor commitment.
• Roadmap sequencing for DX/velocity initiatives. If the roadmap includes "modernize frontend build" or "reduce time-to-first-paint / improve asset caching," this bundle defines the scope of the backend-side work item. It does not change the frontend framework decision, and it does not affect API-only services.
• Laravel applicability: effectively nil. Flagging directly — this is a Symfony bundle, wired through Symfony's DI container and Twig. It cannot be dropped into a Laravel app. Laravel already has a first-party laravel-vite-plugin plus the @vite Blade directive, which is the correct answer for any Laravel codebase. If the org is Laravel-first, this package is out of scope; if the org has Symfony services, it's in scope for those only.
• Migration/consolidation decisions. Relevant when consolidating multiple PHP apps onto one asset pipeline (Webpack Encore → Vite, or bespoke Gulp scripts → Vite). This bundle is a candidate for the Symfony half of that consolidation.
• Platform/infra decisions it touches. HMR requires the dev server to be reachable from the browser; that affects Docker Compose, DDEV/Lando config, and CI caching strategy. Surface this as an infra line item, not a hidden cost.
• Not supported: any decision about SSR, multi-tenant asset isolation, or CDN topology at scale — there's no evidence of adoption here to de-risk those choices.

Adoption signal: 0 stars, 0 dependents, opportunity score ~25/100, single-maintainer risk. Treat as "monitor / spike only." Do not put it on a critical path.

When to Consider This Package

Consider it when all of these hold:

• The codebase is Symfony (not Laravel, not framework-agnostic PHP).
• You are adopting Vite and need manifest + HMR integration with Twig templates.
• You are running a time-boxed spike (1–2 days) to size the integration effort, or you want a readable reference to fork/vendor.
• Your team can absorb the code — i.e., someone can read ~300 lines of PHP and own it if upstream goes quiet.
• MIT license and the ability to vendor the source satisfies your supply-chain policy.

Look elsewhere when any of these hold:

• You're on Laravel. Use the first-party laravel-vite-plugin + @vite directive. Full stop.
• You want a maintained, widely-adopted Symfony integration. Evaluate pentatrion/vite-bundle (the de facto community standard, materially higher install base) or Symfony AssetMapper (first-party, no Node/npm required at all — the strongest option if your frontend is simple and you want to delete the build step entirely).
• You need production guarantees. Zero dependents and zero stars means no downstream users stress-testing edge cases: multi-entry configs, SSR manifests, sub-path deployments, CSP nonces, cache-busting behind a CDN. You'd be the first to find those bugs.
• You need security review sign-off. No adoption footprint means no third-party audit trail; expect to fund your own review.
• The real problem is "we don't want a Node toolchain." That's an AssetMapper decision, not a Vite-integration decision. Don't solve a toolchain-elimination problem with a toolchain-integration dependency.

Net PM recommendation: run a spike; assume you will end up forking or writing the glue yourself. Budget the fork as the base case, not the contingency.

How to Pitch It (Stakeholders)

For executives (one paragraph): Modern PHP apps typically pair a PHP backend with a JavaScript build tool for the frontend. Vite is the current industry default — it makes local development near-instant and produces smaller, better-cached production assets. The catch is that someone has to write the small bridge between Vite and the PHP framework so the app knows which files to load. This package is one such bridge, for Symfony specifically. It is not production-ready on its own: it has no adoption, one maintainer, and no downstream users, so we'd be the ones finding its bugs. The recommendation is a two-day technical spike to size the work, with the expectation that we either fork it or write roughly 300 lines ourselves and own them. For any Laravel services, this is irrelevant — Laravel ships this bridge officially. Decision requested: fund the spike, not the dependency.

For engineering (the honest version):

• It's a thin Symfony bundle: reads manifest.json, resolves entrypoints, emits Twig tags, proxies the Vite dev server for HMR. MIT, released May 2025.
• Integration points are standard and low-magic — this is why it's useful as a reference even if we don't depend on it.
• Risks: no dependents means untested against multi-entry, SSR, sub-path deploys, CSP nonces. Single maintainer = abandonment risk. No security review footprint.
• Weigh against: pentatrion/vite-bundle (established community option) and AssetMapper (first-party, removes Node entirely).
• Ask: timebox a spike; evaluate all three; default to owning the glue rather than depending on a 0-star package.