Download the PHP package eurym3d0n/tailwind-engine without Composer
On this page you can find all versions of the php package eurym3d0n/tailwind-engine. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download eurym3d0n/tailwind-engine
More information about eurym3d0n/tailwind-engine
Files in eurym3d0n/tailwind-engine
Package tailwind-engine
Short Description Enterprise-grade PHP 8.3 package for Tailwind CSS 4 class merging, conflict resolution, and sorting.
License MIT
Homepage https://fox-trotte.fr
Informations about the package tailwind-engine
TailwindEngine
Enterprise-grade PHP 8.5 package for merging, conflict-resolving, and sorting Tailwind CSS 4 class strings.
Replaces ad-hoc string concatenation and implode() calls with a typed,
tested, and extensible pipeline that mirrors the behaviour of the official
Tailwind CSS Prettier plugin.
Requirements
- PHP 8.5 or higher
- No runtime dependencies
Installation
Quick start
Core concepts
Families
Every Tailwind utility belongs to a family — the named group that defines which utilities conflict with each other. Two utilities in the same family with the same variant prefix conflict: the last declaration wins, mirroring CSS cascade behaviour.
Variants
Variant prefixes (hover:, dark:, lg:, etc.) are part of the conflict
key. A variant-prefixed token never conflicts with its base counterpart.
Sort order
The compiled string follows the official Tailwind CSS Prettier plugin ordering: layout and structure first, effects and interactivity last. Base utilities always precede their variant-prefixed counterparts.
API reference
Tailwind — fluent builder
The primary public-facing API. Each method returns a new immutable instance, making partial configurations safely reusable.
Immutability in practice
Because every add* method returns a new instance, a base configuration can
be derived into multiple variants without mutation:
TailwindEngine — direct engine usage
For applications that manage their own class list lifecycle (e.g., building
TailwindClassList incrementally from multiple sources):
Extending the registry
The family registry is split into domain-specific traits. To add custom utility
families, subclass FamilyRegistry and override the two methods:
Then wire the custom registry into the engine:
Architecture
Pipeline
Design decisions
Two sources of truth in FamilyRegistry. getFamilies() and
getSortOrder() are intentionally separate. The merge order in getFamilies()
governs prefix-matching accuracy (more specific prefixes must precede broader
ones within each domain trait). getSortOrder() governs the compiled output
order independently, so a family can be declared in one domain but sorted into
another without any coupling between the two concerns.
Domain traits, not a monolithic list. Each *Families trait owns one
domain. This makes the registry navigable, independently testable, and trivially
extensible without touching a 300-line constant.
Immutable value objects throughout. TailwindClassList, TailwindString,
and the Tailwind builder are all immutable. Base configurations can be derived
into variants safely, and compiled results can be stored without defensive
copying.
Contracts for every pipeline stage. ClassFlattenerInterface,
ConflictResolverInterface, ClassSorterInterface, and
FamilyResolverInterface allow any stage to be replaced or decorated (e.g.,
wrapping ConflictResolver with a caching decorator) without touching
TailwindEngine.
Running the tests
The test suite is structured in three layers:
tests/Core/— unit tests for each pipeline stage in isolation.tests/DSL/— unit tests for the fluent builder API.tests/Integration/— end-to-end tests asserting on the final compiled string.