No-Build Installation

The standard setup in Installation installs @lattice-php/lattice from npm and builds it with Vite alongside your own frontend. If your application is server-driven only — no hand-written React pages, no Node tooling in the deploy pipeline at all — Lattice can ship its own prebuilt bundle instead. One Artisan command and two Blade directives replace the entire npm/Vite half of the setup.

This path is for apps that render through Lattice’s PHP-defined pages, forms, and tables. Custom components and table cells work when they ship as precompiled plugin modules; custom React pages still require the regular installation.

Install

Require the Composer package as usual, then publish the prebuilt bundle:

composer require lattice-php/lattice
php artisan lattice:assets

lattice:assets copies the bundle that ships inside the Composer package into public/vendor/lattice/ — the JS entry, its lazily-loaded chunks, the compiled stylesheet, the icon sprite, and a manifest.json that pins their versions.

Re-run it after every composer update that touches lattice-php/lattice. The bundle version must match the installed package; in debug mode, the @latticeHead directive throws if they drift, so a stale bundle fails loudly instead of silently serving old JS. Automate the republish by adding it to your post-autoload-dump script in composer.json:

"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi",
        "@php artisan lattice:assets"
    ]
}

Wire it into your layout

Add @latticeHead before @inertiaHead, and @latticeScripts after @inertia:

<head>
    @latticeHead
    @inertiaHead
</head>
<body>
    @inertia
    @latticeScripts
</body>

@latticeHead renders the stylesheet link, the theme registered via Lattice::theme() (if any), an import map for the shared React and Lattice runtimes, and a small JSON config script the bundle reads on boot. @latticeScripts renders the module <script> tag for the JS entry. Both read the published manifest.json to version their URLs (?v=<hash>), so browsers pick up new assets after every republish without manual cache-busting.

Custom component plugins

A plugin is a separately precompiled ESM file whose default export satisfies Lattice’s Plugin type. It may import React from react, JSX from react/jsx-runtime, and component helpers or hooks from @lattice-php/lattice/runtime; the import map makes all plugins share the host’s instances.

For an app-owned module, add its public URL to the frontend config:

'frontend' => [
    'path' => 'vendor/lattice',
    'plugins' => [
        '/build/lattice-plugin.js',
    ],
],

You can also override the list for one layout:

@latticeHead(['plugins' => ['/build/lattice-plugin.js']])

Composer component packages can register the same file without app configuration:

{
  "extra": {
    "lattice": {
      "standalone": "dist/plugin.js"
    }
  }
}

php artisan lattice:assets copies each discovered module and adds it to the boot config. All plugin modules load before createLatticeApp; a missing or invalid module stops boot with its URL in the error. Registration after boot is not currently supported.

Configuring realtime

@latticeHead takes an optional array with the same keys as the lattice.frontend config — anything passed to the directive merges over the config file’s values for that render. Publish the config to set defaults that apply everywhere:

php artisan vendor:publish --tag="lattice-config"

'frontend' => [
    'path' => 'vendor/lattice',
    'echo' => null,
    'plugins' => [],
],

echo — passed verbatim to configureEcho() from @laravel/echo-react. When you set it, the boot script dynamically imports the realtime chunk instead of bundling it into the initial lattice.js, so apps that don’t use Realtime pay nothing for it.

Limitations

Custom React pages still require the regular Vite build.
Only Lattice’s built-in icon set; you can’t add your own resources/icons sprite.
English-only chrome. There’s no i18n backend wired in, so Internationalization locale switching doesn’t apply here.
Plugin modules must be single-file ESM builds; additional emitted chunks are not published automatically.

If you outgrow any of these, switch to the regular installation — the PHP side (pages, forms, tables, config) is identical either way; only the frontend delivery changes.