Laravel LSP: A First-Party Language Server for Every Editor

Laravel already ships an official VS Code extension, but developers on Sublime Text, Zed, Neovim, or other editors have relied on community projects to get Laravel-specific autocomplete for things like config keys and route names. Laravel LSP, revealed by Taylor Otwell on stage at Laracon US 2026, moves that intelligence into a standalone, first-party language server that speaks the Language Server Protocol over stdio — meaning any editor with an LSP client can use it, not just the ones Laravel maintains an extension for.

What it actually knows about your app

The server indexes your project and answers editor requests against it. In the announcement demo, typing config('app.time inside a controller produced a completion list of matching config keys with resolved values shown next to them — app.timezone displaying UTC — while an incomplete key surfaced as a diagnostic reading "Config [ap] not found."

Coverage spans most of Laravel's string-keyed conventions:

Document links are what makes view('orders.index') and route('orders.show') clickable in your editor, and the same indexed data backs go-to-definition, enabled by default.

Installing it

composer global require laravel/lsp

Make sure Composer's global vendor bin directory is on your PATH. The package requires PHP 8.2 or newer and ships prebuilt binaries for macOS (arm64 and x64), Linux (arm64 and x64), and Windows (x64).

Editor setup

Sublime Text, Zed, and VS Code each have an official Laravel extension that wires the server in automatically, and Cursor works through the VS Code extension. Neovim and OpenCode need a small amount of manual configuration. For Neovim 0.11+:

vim.lsp.config("laravel_lsp", {
    cmd = { "laravel-lsp" },
    filetypes = { "php", "blade" },
    root_markers = { "artisan", "composer.json", ".git" },
})

vim.lsp.enable("laravel_lsp")

Telling it which PHP to use

The server runs scripts against your project to build its index, so it needs a working PHP command to do that with. A phpEnvironment option, passed through the LSP initializationOptions, controls detection. It defaults to auto, trying Herd, Valet, Sail, Lando, and DDEV in turn before falling back to local PHP — or you can skip detection with an explicit phpCommand array, such as ["./vendor/bin/sail", "php"] for a Sail-based PhpArchitect project.

Every capability is individually toggleable through the same options object — you can disable route diagnostics while keeping route completions, for instance — and there are two dedicated Pest options for keeping generated Pest helper docblocks in sync as tests and autoload files change.

Why a standalone server, not just more editor extensions

Building Laravel-aware intelligence as a standalone LSP server rather than another VS Code-specific extension is the notable design choice here: it's a one-time investment that every current and future LSP-compatible editor benefits from, rather than an ongoing maintenance burden per editor. For teams with developers spread across VS Code, Neovim, and Zed — increasingly common as editor preference fragments further — that means everyone gets the same Laravel-specific intelligence regardless of which editor they've chosen, instead of some team members getting a richer experience than others by accident of tooling.

Full configuration reference and source are on the Laravel LSP GitHub repository.