Preset Tailwindcss Laravel Package

Technical Evaluation

Architecture fit: statamic/preset-tailwindcss is a frontend scaffolding preset for Statamic 2, not a runtime Laravel/PHP package. It ships a tailwind.config.js, a package.json/Laravel Mix build definition, a starter CSS entry, and a small Antlers layout/partial set that a php please preset command copies into a site theme. There is no service provider, no application-facing API, no persistence layer, and no reusable backend logic to plug into a Laravel service topology. From a TPM perspective the architectural question is therefore not "where does this sit in our stack" but "does our target platform still have a preset installer and a Mix-based asset pipeline?" On Statamic 3+ the answer is no, because frontend assets are wired through Vite. This is a reference implementation to copy from, not a dependency to install.

Integration feasibility: Low. Archived since 2019, 22 stars, zero dependents, last release 2019-05-09. It targets a pre-1.0/1.x Tailwind and Statamic 2's preset workflow, so Composer resolution against a current Statamic/Laravel stack will likely fail or drag in stale constraints. The only realistic path is selective extraction: lift tailwind.config.js and the Antlers layout conventions into an isolated branch, then rebuild the pipeline on current Tailwind/Vite. Anything installed directly becomes a permanent internal fork, because no upstream fixes will ever arrive.

Technical risk: High, concentrated in three areas. (1) Build-tool risk — the Mix/webpack pipeline and legacy PostCSS/Tailwind directives are incompatible with current tooling and pull in unmaintained transitive Node dependencies that must clear security review. (2) Content-scanning risk — the preset's purge/content configuration predates modern Tailwind, so dynamically composed class names (bg-{{ color }}-500) get stripped at build time, producing silent visual regressions rather than build errors. (3) Lifecycle risk — archived means no security patches, no compatibility fixes, and no community validation; MIT licensing permits a fork but does not offset the ownership cost. The 0.3 score is consistent with an artifact that should stay out of the production dependency graph.

Key questions:

• Which Statamic and Tailwind versions does the preset target, and does any live project actually match them?
• Is it referenced as a Composer dev dependency, invoked as a preset command, or already vendored/copied into a theme?
• Does it contain any runtime PHP at all, or purely templates, CSS, and build config?
• Can the same outcome be reached with a current official Statamic starter kit plus a maintained Tailwind setup? (Almost certainly yes.)
• What transitive Composer and npm dependencies would be introduced, and do they clear security and license review?
• If we fork, who is the named owner, and what is the exit criterion for retiring it?
• What is the rollback plan if a time-boxed compatibility spike fails mid-sprint?
• Are there accessibility, design-system, or brand requirements a 2019 preset cannot satisfy?

Integration Approach

Stack fit: Poor for current Laravel/Statamic/Tailwind stacks. It fits only a legacy Statamic 2 site already pinned to the matching Tailwind and Mix era. It is inappropriate for headless/API-first frontends, Inertia/React/Vue apps, or any project using modern Tailwind JIT/utility workflows without substantial rework. There is no scenario in which a TPM should approve it as a net-new dependency.

Migration path: Do not install into production. Treat it as a one-shot scaffold and reference: copy the three build files (tailwind.config.js, package.json, Mix config) plus the layout/partial set into an isolated branch, delete the package, and own the result. For legacy sites already depending on it, freeze the current build, inventory templates and CSS surface, replace the preset with an internally owned theme, swap Mix for Vite with @tailwindcss/vite and a manifest, and validate with visual regression and content smoke tests. Run any preset command only on a clean working tree — it writes files non-interactively and will overwrite without prompting.

Compatibility: Assume incompatible until proven otherwise in a disposable spike. Verify Composer resolution, PHP constraints, the preset command's continued existence in the php please namespace, Tailwind config syntax, Node/PostCSS toolchain, hard-coded theme paths, and Antlers rendering after upgrade. Because archived packages receive no upstream fixes, every compatibility patch becomes permanent internal maintenance — price that in before deciding to fork.

Sequencing:

1. Inventory: confirm current Statamic, Laravel, PHP, Node, and Tailwind versions across affected projects; establish which sites reference the preset today.
2. Run a time-boxed compatibility spike in a throwaway branch. Do not merge a package installation.
3. Diff the preset's output against the current official Statamic starter kit and a maintained Tailwind setup.
4. Record an explicit decision: no-go as a dependency; reference-only extraction; or legacy fork with a named owner and sunset date.
5. If extracting, rebuild on Vite + current Tailwind, commit lockfiles, and wire CI with dependency and security scanning.
6. Validate with visual regression, accessibility checks, and content-rendering tests before cutover.
7. Add a dependency-policy guard (allowlist or CI check) so the preset cannot be reintroduced accidentally.

Operational Impact

Maintenance: Zero upstream maintenance; assume frozen. Any use transfers full ownership of patches, dependency updates, build fixes, and template compatibility to us. A fork should be scoped as a small internal artifact with explicit ownership and a documented exit plan, not as a platform component.

Support: No vendor or maintainer support, and effectively no community support given the age and zero dependents. Troubleshooting knowledge lives with whoever knew Statamic 2 Antlers and early Tailwind conventions; documentation will read as stale against current releases. Ramp-up cost is low to inspect but high to modernize safely.

Scaling: Backend scaling is unaffected, but frontend delivery is at risk from stale purge/content configuration producing CSS bloat or missing classes at runtime. Team scaling is the larger constraint: legacy expertise does not spread, and there are no maintained examples to onboard against. Current Tailwind tooling and an official starter kit scale across contributors in a way this preset cannot.

Failure modes: Composer dependency resolution conflicts; the preset command no longer existing or writing to stale hard-coded theme paths; Node/PostCSS/Mix build failures; unrecognized Tailwind directives; silent class stripping from content-scanning gaps; Antlers template render errors after a Statamic upgrade; vulnerable transitive build dependencies; accidental production use because the package still looks installable; and knowledge loss when the last engineer with legacy context leaves.

Ramp-up: Budget a short, bounded compatibility spike to confirm incompatibility cheaply, then default to a rebuild on current official tooling. Treat the package as a reference input — valuable only for its tailwind.config.js and markup conventions — and require an explicit, documented exception before any production use.