laravel-menu: a fluent interface for building menus in Laravel

A Laravel port of a framework-agnostic package

The first substantive line in the readme explains the relationship, and it tells you where to look for the design.

This is the Laravel version of the maintainers' own menu package, adding some extras like convenient methods for generating URLs and macros. The original package is framework-agnostic, so the design decisions, and the awkward parts, live there, and this repository is the Laravel binding of them.

That is a useful thing for an evaluator to know. A framework-agnostic core with thin framework bindings is a shape that shows up in mature libraries, and it means the behaviour of the menu construction is settled and tested in one place while the framework-specific parts stay small.

The tagline in the heading is a fluent interface to build HTML menus in Laravel, and the package description in the repository listing is shorter, an HTML menu generator for Laravel. Both are accurate, and the second is the one to keep in mind when you decide whether it fits: this is a generator that produces HTML markup, not a component that renders a view with slots.

The documentation lives on the maintainers' documentation site rather than in the repository, and the readme points there for usage. There is also a guide for upgrading from version 1, and a note that the project is on its fourth major version, so the shape of the API has changed more than once.

The one example, which is worth reading closely

The readme shows a single example, and it is chosen well, because it demonstrates the two ideas that matter: naming a menu and deciding which item is active.

The menu is defined as a macro on the facade, so the whole navigation lives in one named place.

Menu::macro('main', function () {

Inside the closure, each item is added with an action, a controller action and a label, and the chain ends with a call that sets the active item from the current request.

    return Menu::new()
        ->action('HomeController@index', 'Home')
        ->action('AboutController@index', 'About')
        ->action('ContactController@index', 'Contact')
        ->setActiveFromRequest();

The naming convention is worth noticing, because it is the package's whole idea in one line. The item is not a URL, it is a controller action, and the label is the visible text. So the menu is derived from the application's routes rather than from a list of paths typed by hand, and when a route changes, the menu changes with it. That is why the Laravel version is described as adding convenient methods for generating URLs, because the URL is a consequence of the action rather than an input.

And the active state comes from the request, which is the other half of the problem with hand-written menus. A navigation that cannot tell where you are is a navigation you have to read carefully, and asking the framework for the current request and comparing it against the item is a two-line job once the library has done it.

The readme also offers a second idiom, the raw unescaped output of the menu inside a navigation element, which is what the macro call renders.

<nav class="navigation">
    {!! Menu::main() !!}
</nav>

The double braces mean the markup is not escaped, which is correct for generated HTML and worth knowing about, because that is the kind of decision that matters if the labels ever come from a database.

Installation, and the parts of the readme that are standard

The rest of the readme is short, and the shortness is the point.

The package installs with Composer, and the readme is direct about it.

composer require spatie/laravel-menu

The documentation is on the maintainers' site. The changelog is in the repository, and the readme points at it for what has changed recently. The tests are run with the standard PHP test runner, and the file is a configuration file for it.

$ phpunit

Contributions follow the maintainers' shared contributing guide, which is linked from their organisation rather than duplicated here, and the security policy asks people to mail a security address rather than to file a public issue, which is the correct arrangement for a package that renders unescaped markup.

The credits name the person who wrote the original package and then all the contributors, and the licence is MIT with the file in the repository.

The top level of the tree is correspondingly small. There is a source directory, a tests directory, the Composer manifest, a configuration file for the code style fixer, the configuration for the test runner, an editor configuration, the changelog and the licence file. A package this focused does not need more than that, and a short tree is a reasonable signal that the readme is not hiding anything.

One small thing to note for anyone evaluating the whole set: the readme is a template shared across the maintainers' packages, with the support section, the postcard invitation and the link to the collection of open source projects appearing in each one. That is a reasonable way to run a portfolio of packages, but it means the readme is not a document written for this package alone.

How the project is supported

The support section is about money and postcards, and it is worth reading as a description of how open source projects by commercial agencies usually work.

The maintainers describe themselves as a web design agency based in Antwerp, Belgium, and say they invest a lot of resources into creating packages they describe as being in a class of their own, and that you can support them by buying one of their paid products.

Then the postcard request, which is a genuine open source tradition. They ask that if you enjoy the package, you send a postcard from your hometown mentioning which of their packages you use, and they publish the postcards they receive on a virtual wall.

The part that matters for an adopter is the first one. A package maintained by an agency is maintained by people whose day job is agency work, and the funding model is the paid products. That is a reasonable and honest model, and it is also different from a project maintained by volunteers, which means the release cadence reflects a consultancy's capacity rather than a community's enthusiasm.

The release history is consistent with that reading. Version 4.2.0 came out in February 2024, 4.2.1 in February 2025 and 4.2.2 in February 2026, one release a year, and the last push was on 2026-06-02 with the repository not archived.

So this is a package on a slow, predictable cadence, with a maintainer who is paid to keep it alive, and a version 4 that has been through three minor releases and several major ones. That is a perfectly good profile for a menu generator, and it is worth knowing before you plan around it.

Editorial conclusion

laravel-menu suits a Laravel application whose navigation is defined in code rather than in a configuration file, and whose menus are shared between several pages or rendered from a view helper rather than repeated in templates. It is a poor fit if you want navigation edited by a site administrator at run time, since the menu is a PHP definition, and a poor fit if you want a component library with menu, breadcrumb and pagination handled together. Before you adopt it, read the documentation site rather than the readme, because the readme shows one example and the reference is where the rest of the API lives, and check the changelog if you are upgrading from an older major version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. spatie/laravel-menu on GitHub