Bulma Laravel Package

Technical Evaluation

Architecture fit

• The package is not a runtime library; it is a thin developer-experience shim around Laravel's now-deprecated php artisan preset command. Its entire surface is a service provider (BulmaPresetServiceProvider), an Artisan command extending PresetCommand, and a stubs/ directory containing app.scss, bootstrap.js, layouts/app.blade.php, welcome.blade.php, and the auth view set.
• Because it only writes files during scaffolding, it carries no production runtime footprint, no middleware, no DB surface, and no attack surface. Architectural coupling is limited to Blade templates and the frontend build chain.
• Fit is therefore high for a Laravel 5.5–6 greenfield project that intends to use Bulma as its design system, and effectively zero for anything on Laravel 7+ (where preset was deprecated in favour of laravel/ui) or on Vite-based scaffolding (Laravel 9+).

Integration feasibility

• One-command install (composer require --dev laravel-frontend-presets/bulma then php artisan preset bulma) followed by npm install && npm run dev. Time-to-first-render is under an hour.
• The stub package.json/webpack.mix.js assumptions (node-sass, Laravel Mix, Bulma 0.x) are the main friction point, not the PHP side.
• Feasible as a one-time generator; not feasible as a maintained dependency.

Technical risk

• Obsolescence risk is high: last release 2020-05-09, zero dependents, no signal of active maintenance. The preset command it hooks into no longer exists in current Laravel.
• Toolchain risk is moderate: node-sass does not build on modern Node LTS versions, so a naive npm install on a current workstation will fail even if the Artisan step succeeds.
• Destructive-write risk: the preset overwrites existing resources/views, resources/assets, and auth views. Any prior customisation is lost without a clean working tree.
• Security risk is negligible; supply-chain risk is low but non-zero given an unmaintained dev dependency with a service provider that auto-registers.

Key questions

• What Laravel version is the target, and is the preset workflow still sanctioned internally or superseded by laravel/ui/Vite?
• Is Bulma still the chosen design system, or is this an evaluation of the preset rather than the framework?
• Are we willing to own a forked copy of the stubs, or do we need the package as a named dependency for audit reasons?
• What is the upgrade path if we adopt now and move to Laravel 9+ within 12 months?

Integration Approach

Stack fit

• Fits: Laravel 5.5–6, PHP 7.1–7.4, Blade, Laravel Mix/Webpack, npm. Fits a team already standardised on Bulma utility/component classes.
• Does not fit: Laravel 7+ laravel/ui, Laravel 9+ Vite scaffolding, any project with an established component library or Tailwind-based design tokens.

Migration path

• Recommended: use the package once as a reference implementation. Run it on a throwaway branch, inspect the generated stubs, then vendor the relevant Blade layouts and SCSS into the application repo and remove the Composer dependency. This converts an unmaintained dependency into owned source.
• If the package must remain, pin the exact version and record an explicit deprecation date.
• Post-adoption, replace the Mix/node-sass stub config with the host project's current build tool (Vite or Mix with dart-sass) and import Bulma directly from npm.

Compatibility

• Conflicts with laravel/ui scaffolding; both write the same view paths.
• The stub Bulma version predates several breaking changes in Bulma 0.8/0.9; class names in the shipped views may need reconciliation against whichever Bulma version is actually installed.
• PHP 8 compatibility of the service provider is unverified given the 2020 release date — validate on the target PHP version before committing.

Sequencing

1. Spike on a branch against the target Laravel version; confirm php artisan preset bulma resolves.
2. Capture generated output as a diff; review auth views for auth-scaffolding drift.
3. Vendor stubs into the repo, remove the dependency.
4. Migrate the build tool and pin Bulma to a current minor.
5. Add PurgeCSS/@fullhuman/postcss-purgecss if CSS payload matters.

Operational Impact

Maintenance

• Near-zero ongoing runtime maintenance, but the package itself is unmaintained. Treat it as a template, not a dependency, to avoid inheriting an abandoned-artifact audit finding.
• Internal ownership must be assigned to whoever owns the design system, since no upstream will fix stub regressions.

Support

• Community-only. 170 stars and 0 dependents imply a single-maintainer project with no support contract, no CVE response process, and slow or absent issue triage. Escalation path is "fork it."

Scaling

• No horizontal or runtime scaling impact — it is build-time only. The only scaling-adjacent cost is CSS payload: full Bulma is roughly 200KB unminified, so purge unused classes before production.

Failure modes

• php artisan preset not found on Laravel 7+ — hard failure at install.
• node-sass build failure on Node 16/18/20 — hard failure at npm install.
• Silent overwrite of customised views on re-run — data-loss failure mode; mitigate with a clean tree and review of the diff.
• Version drift between stub Bulma classes and the installed Bulma release — cosmetic/layout regressions discovered late.

Ramp-up

• Minimal. A Laravel-comfortable engineer is productive in half a day; the Bulma class vocabulary is the only new surface. The real cost is not learning the package but unwinding its scaffolding assumptions later.