Bootstrap Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for asset wiring: This package is the "buy" side of a decision that, in practice, is a two-line build. Bootstrap enters a Laravel app via npm install bootstrap + Vite, or a single pinned CDN tag with SRI. Quantifying this bundle's value at "saves one config file" is enough to close the question. Use it as the worked example in any build-vs-buy rubric.
• Dependency adoption policy: With [DEPRECATED] in the title, 1 star, and 0 dependents, this is a clean test case for org-wide minimum maintenance gates (release cadence, dependents, maintainer responsiveness, explicit EOL markers, security response path). It should fail every gate. Codifying those gates is the actual deliverable this package enables.
• Deprecation and EOL handling: Supports a decision on how the org treats upstream EOL declarations — automatic blocklist entry in CI, versus case-by-case review. Recommend the blocklist, with this package as the first entry.
• Roadmap scoping for a Laravel/PHP product: Contributes zero directly. It is a Symfony bundle with no service provider, no Blade directives, no publishable config, and no Twig equivalent in our stack. It does not unblock, accelerate, or de-risk any roadmap item.
• Estate hygiene / tech-debt triage: The only genuine product decision it touches is a removal decision: whether any legacy Symfony app in the portfolio still pulls it in, and what that app's upgrade path off it costs. That's a backlog item with an owner, not a feature input.
• Use case fit: The legitimate uses are (a) legacy Symfony maintenance, and (b) as a reference for how bundles exposed front-end assets pre-AssetMapper. Neither is a product opportunity.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining an existing Symfony application that already requires mremi/bootstrap-bundle, and the task is estimating upgrade or removal cost — not adding it fresh.
• You are auditing a legacy dependency tree and need to document why the package is present and who owns its removal.
• You need a historical reference for pre-AssetMapper bundle asset registration.

Look elsewhere immediately if any of the following hold:

• You are on Laravel. Framework-category mismatch — no bundle registry, no Twig, no Symfony kernel. Nothing will boot it. There is no configuration that fixes this. Use Vite + the Bootstrap npm package, or a CDN link with SRI.
• You need a maintained dependency. Upstream has declared end-of-life; there will be no security patches, no Bootstrap version bumps, and no PHP/Symfony compatibility work. Any CVE landing in its tree becomes ours.
• You are starting a new Symfony project. Use AssetMapper (6.3+) or Webpack Encore with Bootstrap from npm. Standard, supported, better documented.
• You need Bootstrap 5+ behavior. A bundle of the Bootstrap 3/4 era won't track modern releases or their JS component APIs — and aged bundled JS carries known unpatched tooltip/popover XSS classes.
• You need a defensible install. Expect the old Symfony/PHP constraints to conflict with PHP 8.2+/8.3 and a modern dependency graph; a composer update failure blocks CI for unrelated work.

Adoption criteria summary: No new adoption is justified under any reading. The only sanctioned action is a removal/migration decision for existing consumers, plus a CI guard (Composer conflict entry or lint rule) preventing accidental entry into the dependency graph.

How to Pitch It (Stakeholders)

Recommendation: Do not adopt. If it already exists in the estate, schedule removal.

For executives: This package is officially deprecated, has negligible community adoption (1 star, 0 dependents), and is built for Symfony — not our Laravel stack. Adopting it would add an unmaintained dependency with no security patching and no upgrade path, and would put unpatched client-side code in front of our users. The alternative costs under a day of engineering: Bootstrap through our existing Vite build, or a pinned CDN reference. Declining is the lower-cost, lower-risk option, and the decision itself should take under an hour.

For engineering: Treat mremi/bootstrap-bundle as a legacy artifact, not a candidate. For a Laravel service the native path is npm install bootstrap @popperjs/core, imported in app.js/app.scss and built with Vite; form and pagination styling move to Blade components, since Laravel's paginator already ships views. For any Symfony codebase still referencing the bundle, log a migration ticket to AssetMapper or Webpack Encore plus symfony/ux form themes, and drop the dependency. Verify the bundle's PHP and symfony/* constraints first — a conflict against PHP 8.2+/Symfony 6/7 closes the question immediately and gives us a written rejection. Then add the conflict entry so it cannot drift back in. Net takeaway: this is a reference for what not to depend on, and the useful output of this evaluation is the adoption gate, not the package.