Laravel LSP: Bringing First-Party Intelligence to Every Editor

Host: Alex Chan Guest: Marcus Thorne (Lead Developer & Neovim enthusiast) Host: Hey everyone, welcome back to Allur, your go-to spot for everything PHP, Laravel, Go, and the mobile world. I’m your host, Alex Chan. Host: Joining me today to talk about this is Marcus Thorne. Marcus is a lead dev who’s been building Laravel apps for nearly a decade, and more importantly for today’s topic, he is a die-hard Neovim user who has spent way too many hours tweaking config files. Marcus, thanks for jumping on Allur! Guest: Thanks for having me, Alex! And yeah, you called me out there—I’ve definitely spent more time than I’d like to admit trying to get my editor to understand what `Route::get` actually means. It’s great to be here. Host: So, Marcus, let’s start with the "why." You’ve been in the trenches. Was the "VS Code monopoly" as real as it felt for those of us looking in from the outside? Guest: Oh, absolutely. It wasn’t that the Laravel team was trying to be exclusive, it’s just that the community energy was heavily concentrated there. If you used VS Code, you had extensions that felt like magic. You’d type a view name, and it would tell you if the file existed. You’d hover over a Facade, and it would actually show you the underlying class. But if you were on Neovim or Sublime Text? You were essentially writing "plain" PHP and hoping you didn't have a typo in your string-based routes. It felt like a second-class experience for a long time. Host: Right, and that’s a productivity killer. So, for the listeners who maybe hear "LSP" and think it’s just another acronym, can you break down what the Laravel LSP actually *is*? Guest: Yeah, for sure. So, LSP stands for Language Server Protocol. It was actually started by Microsoft, ironically. The idea is: instead of every editor (like VS Code, Vim, Zed, or Sublime) having to write their own specific code to understand PHP or Laravel, we create one "Server." That server is the "brain." It understands the code. Then, any editor—the "Client"—just talks to that server using a standard language. Host: That's the "democratization" part I mentioned. But what does this actually look like when I’m typing? Is it just better autocompletion, or is there more to it? Guest: It’s so much more. I mean, the autocompletion is the "aha!" moment for sure. Like, when you’re in a controller and you type `return view('...` and it starts suggesting your actual Blade file paths. That’s huge. But for me, the real game-changer is the diagnostics. Host: Diagnostics? Like error reporting? Guest: Exactly. Imagine you’re in a Blade file and you use a directive that doesn’t exist, like `@unknwonDirective`. Before, you wouldn't know that was broken until you actually rendered the page in the browser and got an error. Now, the LSP sees it instantly. It underlines it in red right in your editor and says, "Hey, I don't know what this is." It catches missing routes, incorrect config keys—like if you type `config('app.timezonee')` with two 'e's. The LSP knows your config files and warns you immediately. Host: Oh, that’s huge! I can’t tell you how many times I’ve spent ten minutes debugging a "missing" config value only to realize I had a typo in a string. Guest: Exactly! It’s catching those "dumb" mistakes before they ever leave your editor. And then there’s the navigation. Laravel uses a lot of "magic" with Facades and the Service Container. Normally, if you "Go to Definition" on `User::find()`, a basic PHP static analyzer might just take you to the Facade class, which isn't helpful. The Laravel LSP is framework-aware. It knows that `User` is an Eloquent model, and it takes you exactly where you need to go. Host: That sounds like it makes the "magic" of Laravel feel a lot less like… well, a black box. Guest: Exactly. It makes the magic feel like a well-documented tool rather than a mystery. Host: I want to go back to something you said about editors. You’re a Neovim guy. How has this changed your daily workflow? Are you finally feeling like you have the same "superpowers" as the VS Code users? Guest: Honestly, maybe even more, because I get to keep my Neovim speed. Actually, I tried it out on Zed recently too—that new editor everyone’s talking about—and it’s just… it’s seamless. You don't have to go hunting for five different community plugins. You just point your editor to the Laravel Language Server, and suddenly your lightweight editor is as smart as a heavy IDE. It’s incredibly freeing. I don't feel "guilty" for not using VS Code anymore. Host: (Laughs) "Editor guilt" is a real thing! Now, some people might wonder—there were already community LSPs or tools like PHP Intelephense. Why is it so important that this one is "first-party" from the Laravel team? Guest: Reliability, 100%. Community tools are amazing—we wouldn't be here without them—but they’re often playing catch-up. When Laravel 11 or 12 drops a new feature or a new way of doing things, a first-party LSP is going to support it on day one because the people writing the framework are the ones writing the LSP. It’s built *into* the evolution of the framework. That commitment to maintenance is something you can really only get from the source. Host: That makes a lot of sense. It’s about the long-term maturity of the ecosystem. So, looking ahead—this was just announced at Laracon US—where do you see this going? Is this the "final form" of Laravel DX, or just the beginning? Guest: Oh, I think it’s just the foundation. Once you have a server that deeply understands the entire application lifecycle, you can do crazy stuff. I wouldn’t be surprised if we see things like automatic refactoring that understands Eloquent relationships. Like, if you rename a column in a migration, maybe the LSP helps you track down every place you referenced that attribute. Or maybe it gives you N+1 query warnings *while you’re writing the code*, before you even hit the database. Host: Wait, N+1 warnings in the editor? That would be a dream. Guest: Right? The possibilities are massive because the "brain" is now officially connected to the code. Host: This is so exciting. For someone listening who wants to set this up right now—maybe they’re using Sublime Text or Neovim—is it a nightmare to configure? Guest: Not at all. If you’re already using an LSP client in your editor, it’s usually just a matter of installing the Laravel LSP binary—often via Composer or a global install—and adding a few lines to your config. The official Laravel docs have already started putting up guides for the major editors. It’s surprisingly "plug and play" for something this powerful. Host: That’s the Laravel way, isn't it? Making the complex stuff feel easy. Guest: (Laughs) Exactly. "Developer Happiness" is their unofficial motto for a reason. Host: Well, Marcus, this has been awesome. I think a lot of people are going to be dusting off their old favorite editors this weekend to give this a spin. Guest: I hope so! It’s a great time to be a developer. Host: Huge thanks to Marcus Thorne for breaking that down for us.