Bootstrap 4 Laravel Package

Product Decisions This Supports

Primary decision it informs: whether to adopt, tolerate, or retire a legacy front-end scaffold.

• Build vs. buy (build vs. borrow). This package is a thin, unmaintained convenience wrapper: it installs and runs php artisan preset bootstrap4 to swap Laravel 5.5's default auth views, webpack.mix.js, bootstrap.js, and SCSS variables for Bootstrap 4 equivalents. The "build" alternative is roughly 2–4 hours of an engineer's time copying Blade stubs and editing a Mix config. That effort delta is the entire value proposition — useful for knowing this is a convenience decision, not an architecture decision.
• Runtime/platform lock-in assessment. The package targets Laravel 5.5.x specifically. Laravel deprecated front-end presets and replaced them with Laravel UI in the 6.x/7.x era, so this package constrains you to an EOL framework line. Any roadmap conversation about upgrading Laravel immediately makes this package a blocker to remove, not a dependency to keep. That is a roadmap input, not just a tooling one.
• Design-system direction. Adopting it means committing the UI layer to Bootstrap 4 + jQuery + Popper, i.e., pre-2021 front-end conventions. This should be weighed against Tailwind (Laravel's own default direction via Breeze), Bootstrap 5 (no jQuery, no IE), or a component library. The package effectively freezes a design-system choice that will be re-litigated within 12–24 months.
• Prototype and internal-tool triage. The one clean use case: a throwaway internal admin panel or POC on an existing 5.5 codebase where speed-to-demo beats longevity. PMs can use this to greenlight a time-boxed spike without opening a design-system debate.
• Ecosystem-signal reading. Zero stars, zero dependents, opportunity score 16.24 is a clear "no community pull" reading. For a PM, that is a proxy for no upstream fixes, no security triage, no one to ask when it breaks — which matters more than the code itself, since the code is mostly Blade templates and config.
• Vendor/support risk register entry. Low blast radius (it publishes view and asset files, no runtime service, no data path), but non-zero maintenance liability. It belongs on a "known unmaintained dependencies" list with an owner and a sunset date.

When to Consider This Package

Consider it only when all of the following are true:

• You are on Laravel 5.5.x and are not upgrading within the current planning horizon.
• Your app already uses Bootstrap 4 (or must match an existing Bootstrap 4 design system).
• You need auth scaffolding views and asset wiring in minutes, not a maintained component library.
• The work is internal, low-stakes, or disposable — a demo, spike, or back-office tool with no public accessibility or browser-support commitments.
• You are comfortable vendoring the published stubs into your repo and treating them as your own code from that moment on (the correct posture for any unmaintained scaffold package).

Look elsewhere when any of these are true:

• Greenfield or actively upgraded projects. Use Laravel Breeze/Jetstream, Laravel UI, Filament, or Livewire depending on stack; use Bootstrap 5 or Tailwind for styling. None of these need a third-party preset.
• You need Bootstrap 5, no-jQuery, or modern browser/accessibility support. Bootstrap 4 is in maintenance/EOL territory; jQuery-based plugins are an accessibility and bundle-size tax.
• You are building an SPA or Vue/React/Inertia front end. Presets are server-rendered Blade scaffolding; irrelevant.
• Security or procurement review requires a maintained dependency with a named owner, release cadence, or CVE response. This package has none.
• Your team's time is cheaper than your dependency inventory. With zero dependents and no maintainer, the honest comparison is "spend 3 hours writing Blade views" versus "carry an orphaned package through audits for two years."
• You are weighing total cost of ownership. A free package with no maintainer is not free; it is a deferred migration cost.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, community-built helper that makes a Laravel 5.5 application look like Bootstrap 4 in a few minutes instead of a few hours. It is not a platform, not a dependency we should standardize on, and not maintained — no stars, no downstream users, no release cadence. My recommendation is do not adopt it for anything new; where it already exists, treat it as technical debt with a named owner and a sunset date tied to our Laravel upgrade. The cost of adopting is roughly zero; the cost of depending on it compounds, because it pins us to an end-of-life framework version and a superseded CSS framework with jQuery.

For engineering (the ask): If a team wants Bootstrap 4 auth views on a 5.5 app, run the preset once, vendor the generated views and config into the repo, and uninstall the package. That preserves the 3-hour saving without adding an unmaintained entry to composer.json. Do not introduce it as a shared dependency across services, and do not let it appear in a new project's bootstrap. Track removal as part of the Laravel upgrade epic.

Framing the numbers honestly: the opportunity score (16.24) and zero dependents are not a reason to reject the code — the code is trivial Blade and Mix config — they are a reason to reject the dependency. The decision is "copy the output, skip the package," and that framing is the easiest one to get agreement on across product, engineering, and security in a single meeting.