Product Decisions This Supports
- New feature, product, and starter-kit decisions: no-go.
statamic/preset-tailwindcss is an archived (last release 2019-05-09), 22-star, zero-dependent Statamic frontend preset. It should not appear in any new product, starter kit, design-system, or roadmap item. Any proposal that treats it as a candidate dependency is a misread of its lifecycle status.
- Build vs. buy/scaffold. The package is best understood as a historical reference for how Statamic 2 scaffolded Tailwind (config, CSS entry, content paths, Antlers layout conventions), not a buy or reuse option. Modern work should build on current official Statamic starter kits with maintained Tailwind/Vite tooling. “Buy” here would effectively mean “fork and own forever,” which is remediation cost, not strategic investment.
- Roadmap and dependency-policy decisions. Zero dependents and archived status mean negligible ecosystem gravity. It is a strong candidate for an explicit dependency-policy exclusion or CI allowlist check so it cannot be reintroduced accidentally by an engineer following an old tutorial.
- Legacy triage and migration timing. For an existing Statamic 2 project that already references the preset, the real decision is not “should we adopt it” but “when do we freeze, replace, or migrate off it.” Archived status means no security patches, compatibility fixes, or maintainer support, so the PM should fund a scoped migration assessment rather than ongoing support.
- Support, security, and compliance posture. MIT licensing technically permits a fork, but a fork creates permanent internal ownership for patches, build fixes, template compatibility, and transitive Node dependency risk (Mix/webpack, old PostCSS/Tailwind directives). Approve a fork only with a named owner, a time-box, and a documented exit criterion.
- Legitimate, narrow use cases. Historical audits of Statamic 2 frontend setup, migration inventories for old sites, and documentation of legacy preset behavior. It is not appropriate for customer-facing features, current Tailwind adoption, accessibility/design-system work, or headless/API-first frontends.
- Risk-flagging for roadmap assumptions. Any roadmap or architecture assumption that this preset is available, maintained, or compatible with a current Statamic/Laravel/Tailwind stack should be flagged as outdated; the package is a reference artifact, not a platform component.
When to Consider This Package
Consider it only when all of the following are true:
- You are maintaining an existing Statamic 2-era project that already references
statamic/preset-tailwindcss.
- The project’s PHP, Statamic, Tailwind, and Node/build versions are already pinned and working; the frontend stack is not being upgraded as part of this work.
- You need to reproduce, document, or temporarily preserve legacy scaffolding behavior — not introduce a new dependency.
- You accept that the package is archived and unmaintained, and that no fixes, security patches, or compatibility updates will arrive.
- You have a concrete migration, replacement, or removal plan with an owner and a timeline, rather than an intention to keep it long term.
Look elsewhere in nearly every other case:
- New Statamic projects: use current official Statamic starter kits and maintained frontend presets.
- Modern Tailwind adoption: use current Tailwind tooling, Vite/PostCSS pipelines, and your design-system conventions.
- Active support, security, or compliance requirements: an archived 2019 package cannot satisfy them.
- Teams without legacy Statamic 2 exposure: there is no product reason to introduce it.
- Any roadmap expecting long-term maintenance: avoid; there is no maintainer-backed lifecycle.
- Headless, API-first, Inertia, React, or Vue frontends: the preset targets an older Statamic/Antlers and Mix-era build workflow and does not fit without substantial rework.
- Accessibility, brand, or current design-system requirements: a 2019 preset cannot meet them without rebuild.
How to Pitch It (Stakeholders)
Executive summary: statamic/preset-tailwindcss is an archived, low-adoption Statamic frontend preset with no active maintenance and no dependents. It is not a strategic asset and should not be added to new products or planned roadmap work. The only legitimate use is legacy remediation for an existing Statamic 2 project that already depends on it.
For engineering: treat this as a legacy artifact and reference scaffold, not a runtime dependency. Do not install it into new repositories or starter kits. If it appears in an existing project, inventory the pinned Statamic, Tailwind, and Node/build versions; confirm whether the preset is still required; then extract what is useful — primarily the tailwind.config.js and Antlers layout conventions — and rebuild against current Statamic and Tailwind/Vite tooling. Run any preset command only on a clean working tree, since it writes files non-interactively. A fork is legally possible under MIT but creates ownership and maintenance cost without product differentiation. Use a short, time-boxed compatibility spike in a disposable branch and do not merge package installation into mainline.
Product recommendation: allocate no budget for adoption or enhancement. If a legacy dependency exists, fund a small, scoped migration assessment — inventory, replacement, and visual regression testing — rather than ongoing support. The product decision is to avoid new exposure, retire the dependency where practical, and document the choice (plus a dependency-policy guard) so it is not accidentally reintroduced.