Frontend Laravel Package

Getting Started

The package is a Laravel plugin module for the Amplify plugin ecosystem, so treat it as an internal module rather than a standalone library. Installation is the standard Composer path, but because the package has no published usage docs in the wild, read the service provider before writing any code.

composer require amplify/frontend

# Inspect what the package registers and publishes
php artisan vendor:publish --provider="Amplify\Frontend\FrontendServiceProvider"
php artisan about

Where to look first, in this order:

1. vendor/amplify/frontend/src/ — locate the service provider and read the register() and boot() methods. This tells you exactly which config keys, routes, views, and Blade components exist.
2. vendor/amplify/frontend/config/ — copy any config file into config/ and read every key. This is your primary integration surface.
3. vendor/amplify/frontend/resources/views/ — confirm the layout name and the slot/yield conventions before you override anything.
4. composer.json of the package — check the laravel/framework constraint and whether it expects Vite, Livewire, or plain Blade assets.

First use case: render the module's default layout from an existing controller and confirm the asset pipeline loads.

// config/frontend.php (published)
return [
    'layout' => 'frontend::layouts.app',
    'assets' => [
        'driver' => 'vite',
        'entry'  => 'resources/js/app.js',
    ],
];

{{-- resources/views/dashboard.blade.php --}}
@extends(config('frontend.layout'))

@section('content')
    <h1>Dashboard</h1>
@endsection

If that renders without errors and assets resolve, the module is wired correctly and you can start registering your own screens.

Implementation Patterns

Module-first registration. Amplify modules tend to be registered as discrete units. Rather than scattering routes and views, wrap a feature in a single module class or config entry so the frontend module can discover its routes, menu items, and assets together. Keep each module in app/Modules/{Name}/ with routes.php, views/, and a small module.php descriptor.

Layout inheritance over layout replacement. Extend the package layout and fill named sections. Replacing the layout wholesale couples you to internal markup that will break on the next release.

@extends(config('frontend.layout'))

@section('title', 'Orders')
@section('breadcrumbs', Breadcrumbs::render('orders'))

@push('scripts')
    @vite(['resources/js/orders.js'])
@endpush

Menu and navigation registration. Most Amplify frontend modules expose a navigation registry. Register items in a service provider or a dedicated NavigationServiceProvider rather than hardcoding links in Blade, so permissions and ordering stay centralised.

public function boot(): void
{
    Frontend::navigation()
        ->group('Operations', function ($group) {
            $group->item('Orders', route('orders.index'))
                  ->icon('shopping-cart')
                  ->can('viewAny', Order::class);
        });
}

Asset pipeline integration. If the package ships its own compiled assets, avoid mixing them with your Vite build in the same layout. Publish the package assets once and let Vite own only your application entry points. If the package expects a vite.config.js entry, keep that entry in your config and do not rename it on upgrade.

Route → controller → view with a thin presenter. Keep controllers returning views and push data shaping into view models or view composers. Because the frontend module owns the layout, controllers should never construct HTML or inline Blade strings.

Overriding package views safely. Publish views to resources/views/vendor/frontend/ and edit there. Laravel resolves the vendor namespace to your published copy automatically, and you keep a clean diff against the original for future merges.

php artisan vendor:publish --tag=frontend-views

Testing. Use $this->actingAs($user)->get(route('orders.index'))->assertViewIs('orders.index') rather than asserting raw HTML. For menu/permission logic, unit test the registry directly instead of through the rendered page.

Gotchas and Tips

No stars, no dependents means no safety net. Before adopting, read every file in src/; there is no community to surface breaking changes. Pin the version explicitly in composer.json ("amplify/frontend": "1.0.*" rather than ^1.0) and add a smoke test that renders the base layout so an upgrade failure is caught in CI.

The release date looks anomalous. The listed last release (2026-10-21) is in the future relative to normal package timelines. Verify the actual tag on the repository and confirm the composer.json version constraint resolves to a real commit before you build on it.

Publishing is not idempotent. Re-running vendor:publish will overwrite your edits unless you pass --force deliberately. After every composer update, diff vendor/amplify/frontend/resources/views/ against your published copies; layout changes are the most common silent breakage.

Config and view caching hide registration bugs. If a menu item or route vanishes after deploy, run:

php artisan config:clear
php artisan view:clear
php artisan route:clear
php artisan optimize

Registration done inside a closure that depends on the request or auth state will not survive config:cache. Move any request-dependent logic out of config files and into providers or middleware.

Asset driver mismatch is the most common first-run failure. If styles 404, check whether the package expects published static assets, a Vite manifest, or a CDN base URL. Confirm with:

php artisan vendor:publish --tag=frontend-assets
ls public/vendor/frontend

Extension points to prefer. Look for events, a navigation/menu registry, Blade components, and a module resolver interface in the package source. These are the stable seams. Subclassing the service provider or editing vendor files is not — both break on the next release.

Debugging visibility. Because there is no documentation, use php artisan about plus a quick dd(app(\Amplify\Frontend\Frontend::class)) in a Tinker session to enumerate the public API. Reading the container bindings is faster than guessing config keys.

Fallback plan. Keep the module behind a thin application-level abstraction (your own Dashboard facade or Blade component wrapper). If the package stalls at zero dependents, swapping it out becomes a single-file change rather than a rewrite of every view.