On Fri, Oct 31, 2025, 8:48 a.m. 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*
>
> 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.
>