Layout Laravel Package

Product Decisions This Supports

• Build vs. buy for presentation/layout plumbing: ateliersvg/layout is a small, single-purpose utility package (currently centered on text-wrapping behavior, per the WrapsText extraction in v0.8.0). It supports the "buy" side of the decision for low-differentiation rendering helpers — adopt it rather than maintain bespoke layout/text-formatting code in-house.
• Feature scoping for content-heavy surfaces: anything we ship that renders variable-length text into constrained spaces (cards, PDF exports, notification/email templates, admin tables, CLI output) is a candidate use case. The package is a supporting dependency, not a user-facing feature — treat it as an implementation detail behind our own view components.
• Roadmap sequencing: at v0.x, this is not a foundation to build a platform strategy on. Any roadmap item that depends on it should be scoped so the dependency is swappable (thin adapter, no direct calls scattered through Blade templates or domain code).
• Dependency governance: the v0.8.0 release is an internal refactor (extracting WrapsText), which is exactly the kind of change that can move public API in a pre-1.0 package. This supports a standing decision to pin the version and review changelogs on upgrade rather than floating to ^0.8.
• Not a differentiator: no roadmap weight should be assigned to it. It should not appear in customer-facing commitments or marketing.

When to Consider This Package

Consider it when:

• We have a concrete, narrow need for text wrapping/layout helpers in Laravel views, mail templates, or exports, and the alternative is writing and maintaining that logic ourselves.
• The behavior is genuinely commodity — we gain nothing from owning the code.
• We can isolate it behind a small internal abstraction (e.g., our own Blade component or helper) so a future replacement is a one-file change.
• We are comfortable with pre-1.0 semver: minor bumps may carry behavior or API changes, as v0.8.0's refactor illustrates.

Look elsewhere when:

• The package is load-bearing for a customer-facing, high-traffic surface where a mid-cycle breaking change is expensive — prefer a 1.0+ dependency or vendor the specific logic.
• We need guarantees on maintenance cadence, security response, or long-term support; a single-maintainer v0.x package does not provide these.
• Our actual need is broader layout/composition (grids, responsive systems, design tokens) — this package is narrower than that, and adopting it would not solve the real problem.
• The team would end up patching or forking it, which converts "buy" back into "build" without the control.

How to Pitch It (Stakeholders)

For executives (one line): A small open-source utility we can use instead of building text-layout helpers ourselves; it saves a little engineering time, carries low strategic weight, and is pinned so changes cannot surprise us.

For engineering leadership: ateliersvg/layout v0.8.0 is a pre-1.0 Laravel/PHP package whose latest release extracts WrapsText — an internal refactor, not a feature. That is a signal about the package's maturity: expect the public surface to keep moving on minor versions. Recommendation is to adopt only behind a thin internal adapter, pin the exact version, and require a changelog review plus a full test-suite run on every bump. Do not let it leak into Blade templates or domain code directly.

Ask: approve adoption for a single scoped use case as a time-boxed pilot, with the adapter as a hard condition and a documented fallback (vendor the wrapping logic) if the package churns or stalls. No long-term dependency commitment until it reaches 1.0 or proves stability across several releases.