Tachyons Laravel Package

Technical Evaluation

What this package actually is. Not a runtime library but a scaffolding plugin for Laravel 5.5: it registers with the framework's php artisan preset command and, when invoked, copies Blade layouts, a Tachyons CSS entry point, and a webpack.mix.js/package.json fragment into the host application. Its entire value is delivered once, at scaffold time, and it leaves no code on the request path. That single fact should drive the whole evaluation — it means the risk profile is "what did it overwrite and what build toolchain assumptions did it bake in," not "what happens under load."

Architecture fit. Conditional and narrow. The package targets the Laravel 5.5 LTS generation; php artisan preset was removed in Laravel 6, and the accompanying Mix/webpack 3 build fragments predate Vite entirely. For any application on Laravel 9/10/11/12 the package cannot be installed and invoked as designed. Fit is therefore limited to legacy 5.5–5.8 applications, which is a shrinking set.

Technical risk. High, and mainly supply-chain and abandonment rather than correctness. Last release October 2017, nine stars, zero dependents, single maintainer, no CI matrix or test signal. Critically, the earlier product memo reads the 1.0.0 tag as a semver stability commitment — that reading is wrong here. A 1.0.0 followed by eight years of silence is a frozen artifact, not a supported public API; there is no one to honour a breaking-change policy. If the preset pulls 2017-era npm dependencies (node-sass, webpack 3), those are both unpatched and incompatible with current Node versions.

Key questions.

• What is our actual Laravel baseline, and is any target app still on 5.5–5.8?
• Is the requirement "Tachyons specifically" or "utility-first CSS"? These have very different answers — the former is a two-day port, the latter is a Tailwind decision.
• Does our current frontend build (Mix vs. Vite) and CSS pipeline have an owner, and would a preset overwriting resources/views/layouts/app.blade.php bypass design review?
• Are we prepared to vendor the stubs and own them, or are we expecting upstream fixes that will never come?

Integration Approach

Stack fit. Assume this does not install. Treat the repository as a reference implementation and a source of stubs, not as a dependency. The legitimate path for a modern Laravel application is to take the Tachyons CSS asset and the markup patterns and wire them into the existing Vite pipeline by hand — roughly half a day to two days of work, which is well under the cost of owning an abandoned Composer dependency and the review overhead that comes with it.

Migration path. Two distinct paths, decided explicitly rather than by default:

• Legacy 5.5–5.8 app: composer require on a clean branch, run php artisan preset tachyons, and diff the result line by line before committing. Pin the version exactly; do not use ^1.0 here, since minor releases are not coming and the caret buys nothing.
• Modern app: no package. Copy the Blade layout and Tachyons entry point, import the stylesheet from resources/css/app.css, and adjust the markup for current Blade component conventions. Record in an ADR that we deliberately did not adopt the package and why.

Compatibility checks before any merge. Presets are destructive by design — they overwrite welcome.blade.php, layout files, and sometimes routes/web.php and auth views. Run in a throwaway branch, diff against the working tree, and confirm the preset class does not assume a specific Mix manifest path or a public/css/app.css output that our build no longer produces. Confirm PHP constraint and the laravel/framework constraint resolve against our locked versions before anything else.

Sequencing.

1. Confirm the requirement is Tachyons-the-design-system, not utility-CSS-in-general.
2. Timebox a half-day spike: install or port on a branch, produce a working page, note every deviation from the preset's assumptions.
3. Decide adopt-vs-vendor-vs-rebuild, and write it down.
4. If vendoring: move the preset class and stubs in-repo, delete the Composer requirement, add a header comment naming the origin and licence (MIT).
5. Design/accessibility review of the generated Blade markup — 2017 scaffold markup rarely meets current contrast, focus-state, and semantic-HTML expectations.
6. Roll forward to a reference implementation other teams can copy.

Operational Impact

Maintenance. Effectively none available upstream. If adopted, the package becomes internally owned code from day one; assign an owner and add it to the dependency-review register with an explicit "frozen, do not expect updates" note. The maintenance burden itself is small (static CSS, static Blade), which is the one favourable property here.

Support. No upstream escalation path exists. Define the internal boundary clearly: defects in the ported styles and markup are ours; there is no vendor to blame. If the package remains in composer.json, expect routine security tooling to flag its 2017-era transitive dependencies, and decide in advance whether the response is "vendor and remove" or "allowlist with justification."

Scaling. Negligible runtime impact — CSS is static and Tachyons is small (tens of KB uncompressed). The only scaling consideration is the build pipeline: if the preset's Mix configuration is adopted wholesale, it constrains Node version and blocks a future Vite migration. PurgeCSS-style trimming is optional with Tachyons and generally not worth configuring.

Failure modes to test. Preset invocation silently overwriting customised views; the preset command not existing on Laravel 6+ (fails confusingly, not loudly); node-sass/webpack 3 build failures on modern Node; CSS loading broken by a changed asset path or manifest; and the preset assuming a directory layout our app has since reorganised.

Ramp-up. Low for anyone fluent in Blade and CSS. The real cost is class-name translation: engineers trained on Tailwind will not intuit Tachyons' naming (pa3, f4, near-black, mw7), so budget a day for a short internal style card and one exemplar page. Do not roll out to multiple teams until that exemplar exists — otherwise each team invents its own conventions and the utility-first benefit inverts into inconsistency.