Plinth Laravel Package

Getting Started

Plinth is distributed as both a Composer package (ptbdynamic/plinth) and an npm package (@ptbdynamic/plinth). For a Laravel app, install both sides:

composer require ptbdynamic/plinth
npm install @ptbdynamic/plinth

Start with the GitHub release notes for 0.1.0, since v0.1.1 is a packaging fix rather than a feature release. Then check the package README for any Laravel service-provider auto-discovery, config publishing, or asset publishing tags.

A good first use case is to import the shared CSS/tokens into your frontend entrypoint and use one Vue or React component subpath, rather than adopting the whole package at once:

import '@ptbdynamic/plinth/css';

// Vue
import { /* component */ } from '@ptbdynamic/plinth/vue';

// React
import { /* component */ } from '@ptbdynamic/plinth/react';

// Tokens
import { /* token */ } from '@ptbdynamic/plinth/tokens';

Implementation Patterns

Install both registries together. The PHP and npm packages share the ptbdynamic naming, so keep both dependencies visible in composer.json and package.json. Treat them as a paired surface: backend integration through Composer, frontend primitives through npm.

Use subpath imports deliberately. Plinth exposes /vue, /react, /tokens, /css, and additional subpaths. Import only the surface you need so you do not pull unrelated framework code into your bundle.

Centralise tokens. If you use Plinth tokens in both Blade/PHP and JS, define them once through @ptbdynamic/plinth/tokens and reference them from your app’s CSS or component layer. Avoid duplicating colour/spacing values in Laravel config and frontend code.

Laravel asset pipeline. Import @ptbdynamic/plinth/css from your main CSS entrypoint, typically resources/css/app.css, or from your Vite JS entrypoint if the package expects that. Keep the import order consistent with your Tailwind/base styles.

Publish only what you need. If the package exposes config or assets via vendor:publish, publish them into the host app only when you need to override defaults. Prefer package defaults until a concrete customisation is required.

Version alignment. Because two registries are involved, pin both sides during early adoption:

{
  "require": {
    "ptbdynamic/plinth": "^0.1.1"
  },
  "dependencies": {
    "@ptbdynamic/plinth": "^0.1.1"
  }
}

Gotchas and Tips

Use the exact npm scope. v0.1.1 fixes the npm package name to @ptbdynamic/plinth. If you previously referenced any other scope or package name, update imports to @ptbdynamic/plinth and leave the subpaths as-is (/vue, /react, /tokens, /css, etc.).

v0.1.1 is not a feature release. The meaningful changes are registry publication and npm naming alignment. Do not expect new APIs from this bump; review the 0.1.0 notes for actual functionality.

Early-stage API stability. At 0.1.x, treat public APIs and subpath exports as unstable. Pin versions and read release notes before minor bumps.

CSS not applying. Check that @ptbdynamic/plinth/css is imported in the correct entrypoint and in the right order relative to Tailwind or other global styles. Clear the Vite cache if imports appear stale:

rm -rf node_modules/.vite
npm run dev

Debugging installed versions. Verify both sides independently:

composer show ptbdynamic/plinth
npm ls @ptbdynamic/plinth

Extension points. Look for a publishable Laravel config file and documented subpath exports before reaching into package internals. If the README does not document an override, prefer wrapping Plinth components in your own app-level components rather than modifying vendor files.