On Fri, Oct 31, 2025, 8:48 a.m. Dan Jessen <[email protected]> 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* > > 1. Toolchain Completeness > A programming language should ideally include its own ecosystem of > core tools — including syntax checking, testing, and language intelligence. > 2. 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. > 3. Standardization > A unified and standardized LSP implementation would reduce > fragmentation and improve interoperability across IDEs and plugins. > 4. 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 > I actually had a similar idea like 2 years ago and started working on a golang port of nikics parser. Its still a side project and not yet well documented, but it works and its significantly faster. I can make it presentable and publish it this weekend if theres any interest in going this route Cheers, Hammed. >
