Re: Fwd: [DISCUSSION] Proposal: Official PHP Language Server (LSP Implementation)

From: Date: Fri, 31 Oct 2025 17:17:12 +0000
Subject: Re: Fwd: [DISCUSSION] Proposal: Official PHP Language Server (LSP Implementation)
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-129032@lists.php.net to get a copy of this message
> On Oct 31, 2025, at 10:50, Dan Jessen <danjessen@gmail.com> wrote:
> 
> 
> Hello everyone,
> 
> I’d like to start a discussion about the potential for PHP to have an official Language
> Server, implementing the Language Server Protocol (LSP) — similar to what other programming
> languages already provide (e.g.. Go’s gopls, Elixir’s Expert, etc.).
> 
> This is not yet a formal RFC, but rather an exploration of whether there’s community interest
> in such a concept, and what form it could take if we agreed it’s worth pursuing.
> 
> Background / Motivation
> Currently, PHP developers rely on various third-party or editor-specific language servers,
> including Psalm, Intelephense, and phpactor. These tools are impressive, but they differ in
> capabilities, maintenance status, and licensing (some are commercial).
> Additionally, several editors (e.g. VS Code, PhpStorm) implement their own non-standardized
> integrations.
> 
> By contrast, many modern languages now provide an official language server as part of their
> toolchain. For example:
> Go: gopls
> Elixir: Expert (official successor to the community-built ElixirLS)
> Rust: rust-analyzer
> TypeScript: TypeScript Server
> These servers improve consistency, tooling integration, and accessibility — independent of
> any specific IDE or vendor.
> 
> Why PHP Could Benefit
> Toolchain Completeness
> A programming language should ideally include its own ecosystem of core tools — including
> syntax checking, testing, and language intelligence.
> Editor Independence
> PHP is often associated with PhpStorm because of its strong analysis features. An official LSP
> would level the playing field, enabling advanced features in any editor that supports the protocol.
> Standardization
> A unified and standardized LSP implementation would reduce fragmentation and improve
> interoperability across IDEs and plugins.
> Accessibility and Onboarding
> Lowering the barrier for new developers by providing consistent, out-of-the-box editor support.
> 
> Existing Building Blocks
> The PHP runtime already provides components that could serve as a foundation — e.g. php -l
> for syntax checking, reflection APIs, AST via php-ast, and insights from static analysis tools like
> Psalm or PHPStan.
> 
> This wouldn’t necessarily mean rewriting existing tools, but defining a common standard —
> potentially leveraging or integrating with those efforts.
> 
> Next Steps
> I’m not currently in a position to build such a server myself, but I’d like to open a
> discussion around:
> Whether this aligns with PHP’s roadmap and philosophy.
> Any prior work or discussion on the topic.
> The potential scope — e.g., core toolchain addition, PECL extension, or standalone PHP
> project under the official organization.
> If there’s interest, I’d be happy to draft a more formal RFC to outline possible goals,
> structure, and implementation paths.
> 
> Thanks for reading — I’d really appreciate your thoughts, pointers to prior work, or any
> guidance on how best to take this forward.
> 
> Best regards,
> Dan

Would such a thing need to be in php-src, or could it be started as a separate code base? IOW, could
this be an independent project maintained outside of internals and donated to the PHP project?

Cheers,
Ben



Thread (7 messages)

« previous php.internals (#129032) next »