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

Mailing Lists php.internals
1

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

2

Hello.

Great idea.

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.

At the moment, PHP has several static analyzers.
But what would be really great is the ability to extend and combine
them — for example, having a separate module that determines the data
type of a variable. That component would be invaluable and could be
reused for various purposes, not just within LSP.

In JavaScript, the equivalent of such a “ring of power” was the Babel
project, which allowed manipulating the AST and writing custom
plugins. I think PHP could benefit greatly if such a tool were built
as a standard for AST analysis, allowing small plugins to be created
for it with minimal effort.

---
Ed

3

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

  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

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

4

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.

5

Just reporting on existing language servers that already exist, and go way ahead of PHP in terms of supported type declarations.

Note that the PHP spec is quite limited on more refined types (like int<1, max> and such, as an example), so I wouldn’t expect an “official” LSP to support it.

···

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

1 Like
6

Thanks Marco — I agree that any official LSP should follow the PHP spec closely and avoid adding new type semantics.

The issue isn’t the lack of servers, but fragmentation. Psalm and Phpactor differ in scope and design, while Phan’s LSP docs haven’t been updated in years and its Vim plugin is around seven years old. None are standardized or maintained alongside PHP itself.

PhpStorm is an excellent IDE, but it’s premium — and the fact it’s the only consistently recommended option highlights a tooling gap. Developers using VS Code, Neovim, Emacs, or Sublime Text often get a very different experience.

The Language Server Protocol exists to solve exactly this: as Tom Djenius de Vries put it, it turns the M×N problem (M editors × N languages) into M+N — each only needs one integration point.

A spec-aligned, officially maintained PHP LSP could unify that baseline and make PHP development more consistent and accessible across editors.

Best,
Dan

···

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

7

On Nov 1, 2025, at 14:38, Dan Jessen danjessen@gmail.com wrote:

Thanks Marco — I agree that any official LSP should follow the PHP spec closely and avoid adding new type semantics.

The issue isn’t the lack of servers, but fragmentation. Psalm and Phpactor differ in scope and design, while Phan’s LSP docs haven’t been updated in years and its Vim plugin is around seven years old. None are standardized or maintained alongside PHP itself.

PhpStorm is an excellent IDE, but it’s premium — and the fact it’s the only consistently recommended option highlights a tooling gap. Developers using VS Code, Neovim, Emacs, or Sublime Text often get a very different experience.

The Language Server Protocol exists to solve exactly this: as Tom Djenius de Vries put it, it turns the M×N problem (M editors × N languages) into M+N — each only needs one integration point.

A spec-aligned, officially maintained PHP LSP could unify that baseline and make PHP development more consistent and accessible across editors.

IMO, this is something that would work best as a working group involving the maintainers of PHPStan, Psalm, PHP CodeSniffer, PhpStorm, and the related VS Code extensions, since all of these projects have an interest in a spec-aligned PHP LSP. Perhaps PHP-FIG could be a good host for this working group?

Cheers,
Ben