feat: laravel_lsp

[abdellatif-temsamani]

Summary

• add a configuration for the official Laravel language server
• enable PHP and Blade files
• start the server only when an artisan project root is found

Motivation

Laravel maintains a separate language server at laravel/lsp. The existing laravel_ls configuration targets the unrelated laravel-ls/laravel-ls project, so users of the official server currently need to define a custom Neovim configuration.

Impact

Users can enable the official server with:

vim.lsp.enable('laravel_lsp')

Non-Laravel PHP projects are unaffected because the configuration requires an artisan root marker.

Validation

• stylua --check lsp/laravel_lsp.lua
• headless Neovim config loading and root callback assertions
• bash .github/ci/lint.sh origin/master HEAD
• git diff --check

The full Vusted and EmmyLua checks were not run because vusted and emmylua_check are not installed locally.

[justinmk]

The existing laravel_ls configuration targets the unrelated laravel-ls/laravel-ls project, so users of the official server currently need to define a custom Neovim configuration.

Well this is confusing. How are users supposed to know which one to choose? They both look similar.

Is laravel-ls/laravel-ls still relevant, what are the tradeoffs?

[abdellatif-temsamani]

The existing laravel_ls configuration targets the unrelated laravel-ls/laravel-ls project, so users of the official server currently need to define a custom Neovim configuration.

Well this is confusing. How are users supposed to know which one to choose? They both look similar.

Is laravel-ls/laravel-ls still relevant, what are the tradeoffs?

I don't know about laravel-ls/laravel-ls but 'Laravel/lsp' is provided by the laravel team

[abdellatif-temsamani]

@justinmk I looked into both implementations more closely.

• [laravel/lsp](https://github.com/laravel/lsp)
  is the official Laravel-maintained server. It is PHP-based, installed through
  Composer as laravel-lsp, and currently covers a broader Laravel surface:
  Blade components, translations, middleware, Livewire, Inertia, authorization,
  validation, Eloquent, and multiple PHP environments such as Sail, Herd, Valet,
  DDEV, and Lando.
• [laravel-ls/laravel-ls](https://github.com/laravel-ls/laravel-ls)
  is an independent Go implementation exposed as laravel-ls. It is still
  maintained and not deprecated or archived. It supports the core routes, views,
  config, environment, bindings, and assets features, with some distinct
  functionality such as route-action inlay hints and code actions for creating
  missing resources. It also offers standalone binaries and existing Mason
  support.

Therefore, I don’t think the existing configuration should be replaced.
laravel_lsp should be the recommended choice for most users, while
laravel_ls remains available for users who prefer the community Go
implementation or depend on its specific features.

I can also update both configuration descriptions to cross-reference each other:

• laravel_lsp: official Laravel-maintained language server
• laravel_ls: community Go language server; see laravel_lsp for the official
  implementation