Plinth Laravel Package

Product Decisions This Supports

• Build vs. buy for design-system plumbing. Plinth pairs a Composer package (ptbdynamic/plinth) with an npm package (@ptbdynamic/plinth) exposing Vue, React, tokens, and CSS subpaths. That lets a Laravel product team adopt one shared token/component source of truth instead of maintaining parallel Blade and JS implementations — a decision worth costing against 2–4 weeks of internal scaffolding plus ongoing drift.
• Roadmap sequencing for a shared UI layer. The /tokens and /css subpaths mean design tokens can land ahead of framework-specific components. A PM can sequence: tokens → CSS baseline → one framework (Vue or React) → second framework, rather than committing to a full component migration up front.
• Framework-agnostic positioning. Supporting both Vue and React from one Laravel-side package is relevant if the org has mixed front-ends (e.g., an Inertia/Vue admin plus a React customer app). This is a genuine differentiator versus Blade-only or single-framework kits.
• Use cases this fits: internal admin panels, Inertia-based apps, multi-product orgs standardising look-and-feel, and teams wanting tokens consumable by both PHP-rendered and JS-rendered surfaces.
• Release-cadence signal for planning. The v0.1.1 patch is packaging-only — the npm scope was renamed to @ptbdynamic/plinth to match the GitHub org and Composer vendor, with subpaths (/vue, /react, /tokens, /css) unchanged. This is a good sign for governance (one consistent namespace) but confirms the project is still normalising its own identity at 0.1.x. Do not put this on a committed delivery date yet.

When to Consider This Package

Adopt (or, more accurately, spike) when:

• You are starting a new Laravel app or a new front-end surface where the cost of adopting a convention is low and there is no legacy component library to displace.
• You need one token source feeding both server-rendered and JS-rendered UI, and you are willing to own the fallback path if the package stalls.
• Your team already lives in the ptbdynamic ecosystem, or you are comfortable being an early adopter who can file issues and pin versions.
• You can absorb a 0.x breaking change without a customer-visible incident — i.e., the surface is internal or behind a feature flag.

Look elsewhere when:

• You need stability guarantees, LTS, or a security-response commitment. At v0.1.1 there is no evidence of a support policy, changelog depth beyond a pointer to 0.1.0, or a deprecation process.
• You need accessibility conformance evidence (WCAG audit, keyboard/screen-reader coverage) or documented browser support — none is surfaced in the release material.
• Your stack is Blade/Livewire-only. The value proposition is concentrated in the Vue/React subpaths; a Blade-only team gains mainly tokens and CSS.
• The npm rename matters to you: any team that installed the pre-0.1.1 npm package under the old name must update package.json and lockfiles. Import paths inside application code are unaffected (subpaths unchanged), so migration is a dependency-declaration change, not a code rewrite — but it is a real coordination task across repos.
• You require semantic versioning discipline before committing architecture to it.

How to Pitch It (Stakeholders)

To executives (one paragraph): Plinth is an early-stage, low-cost bet that lets our Laravel apps share one design language across both server-rendered and JavaScript front-ends, instead of us building and maintaining that glue ourselves. It is pre-1.0, so the recommendation is a time-boxed evaluation on one internal surface — not an org-wide standard — with a clear exit if it doesn't mature. The upside is avoided custom work and visual consistency; the risk is vendor immaturity, which we contain by pinning versions and keeping the token layer portable.

To engineering: The v0.1.1 release is a packaging fix, not a feature release. The npm package is now @ptbdynamic/plinth, matching the GitHub org and Composer vendor; subpath imports (@ptbdynamic/plinth/vue, /react, /tokens, /css) are unchanged. Practical actions: update package.json and lockfiles anywhere the old npm name was used, and pin exact versions given 0.x semantics. The Composer side is unchanged. Treat the package as an evaluation dependency: wrap adoption behind our own thin abstraction over the token/CSS layer so swapping it out later is a contained change, and confirm before committing that it meets our accessibility and browser-support bars — those are not yet documented in the release notes.