- What is kamona/fortify-bootstrap and what does it actually install?
- It is a scaffolding generator for Laravel Fortify, not a runtime library. Fortify ships headless authentication routes, controllers, and actions with no UI, and this package publishes Bootstrap 5-styled Blade views plus related auth wiring so you get ready-made login, registration, password reset, and email verification screens. Once published, the package effectively steps out of the way and the copied files become yours to own.
- Which Laravel and Fortify versions does kamona/fortify-bootstrap support?
- The last release was 2022-03-04, so it predates Laravel 10 and 11 and has no published test matrix. Fortify's view contracts, route names, and action signatures have moved since then, so do not assume compatibility from the composer constraint alone. Spike it in a throwaway app on your target Laravel version and verify each auth flow end to end before committing.
- How do I install kamona/fortify-bootstrap in a Laravel application?
- The sequence is composer require kamona/fortify-bootstrap, then php artisan vendor:publish to emit the views and assets, then run Fortify's migrations. Confirm the FortifyServiceProvider is registered and that Fortify's auth view resolution points at the published Blade files. There are no service container changes or middleware rewrites involved; the friction is version fit, not wiring.
- Does kamona/fortify-bootstrap use Vite or Laravel Mix?
- A 2022-vintage scaffold almost certainly assumes Laravel Mix, while current Laravel defaults to Vite. Expect to reconcile the CSS and JS entry points and replace mix() calls with @vite directives, or drop the package's asset wiring entirely and load Bootstrap through your app's existing Vite setup. The Bootstrap 5 markup itself is stable; it is the surrounding build ergonomics that need updating.
- Which auth screens does it include, such as 2FA, email verification, and password confirmation?
- The core happy paths are login, registration, password reset, and email verification. Newer Fortify features such as updated two-factor authentication and password-confirmation flows may not have matching views in a 2022 view set, so inspect the published resources/views/auth directory before you plan around them. Anything missing has to be hand-written against Fortify's current view variables.
- Is kamona/fortify-bootstrap still maintained?
- No. It has a single maintainer, six stars, zero dependents, and a last release in March 2022, with no security policy or upstream patch stream. Treat it as a one-time template rather than a dependency you can rely on for fixes. The practical mitigation is to publish the files into your own repository and own them.
- Should I keep kamona/fortify-bootstrap in composer.json after publishing?
- No, or at most pin it to an exact version for reference. Adopt it as a seed: spike in a throwaway app, publish views and assets, verify each Fortify feature, then commit the published code as first-party code and remove the package. That converts a stale, low-adoption dependency into something your team controls and can patch.
- How does kamona/fortify-bootstrap compare to Laravel Breeze or Jetstream?
- Breeze and Jetstream are first-party and actively maintained but Tailwind-first, so adopting them commits your auth surfaces to Tailwind. This package is one of the few off-the-shelf Bootstrap 5 scaffolds for Fortify, which is its entire value proposition. Choose it only if your organization has standardized on Bootstrap 5; otherwise you end up maintaining a parallel design system for auth alone.
- Are there security concerns with using a stale authentication scaffold?
- A stale template is not automatically insecure, but it is unmonitored: no CVE feed, no security policy, and nobody to notify if an issue appears. Auth views are where CSRF tokens, validation error rendering, and credential forms live, so review those templates line by line after publishing. Once the code is in your repo, add it to your normal review and dependency-watch process.
- How should I test the published views and Fortify flows?
- Write feature tests against each endpoint you ship: login, registration, password reset, and email verification, plus any 2FA or password-confirmation routes you add. Run them on your target Laravel and Fortify versions immediately after publishing, since that is where drift shows up. Keep the tests in your app repo so future Laravel upgrades catch broken view variables or route name changes.