Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129030
Precedence: list
MIME-Version: 1.0
References: <CAFJFTYZK+FD+02YXmW9NuNoOfepyZYVZTWDJVSD18rodHfnZDQ@mail.gmail.com>
In-Reply-To: <CAFJFTYZK+FD+02YXmW9NuNoOfepyZYVZTWDJVSD18rodHfnZDQ@mail.gmail.com>
Date: Fri, 31 Oct 2025 15:47:28 +0100
Message-ID: <CAFJFTYb2+mGT-YJZ23qjrQYuuVdqRAv7G16iZhZDMgx6f3NvyQ@mail.gmail.com>
Subject: [PHP-DEV] Fwd: [DISCUSSION] Proposal: Official PHP Language Server (LSP Implementation)
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000bf7f00642757488"
From: danjessen@gmail.com (Dan Jessen)

--0000000000000bf7f00642757488
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I=E2=80=99d like to start a discussion about the potential for PHP to have =
an
official Language Server, implementing the Language Server Protocol (LSP) =
=E2=80=94
similar to what other programming languages already provide (e.g. Go=E2=80=
=99s
gopls, Elixir=E2=80=99s Expert, etc.).

This is not yet a formal RFC, but rather an exploration of whether there=E2=
=80=99s
community interest in such a concept, and what form it could take if we
agreed it=E2=80=99s 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 =
=E2=80=94
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 =E2=80=94 including syntax checking, testing, and language intelli=
gence.
   2. Editor Independence
   PHP is often associated with PhpStorm because of its strong analysis
   features. An official LSP would level the playing field, enabling advanc=
ed
   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 =E2=80=94 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=E2=80=99t necessarily mean rewriting existing tools, but defini=
ng a
common standard =E2=80=94 potentially leveraging or integrating with those =
efforts.

*Next Steps*
I=E2=80=99m not currently in a position to build such a server myself, but =
I=E2=80=99d like
to open a discussion around:

   - Whether this aligns with PHP=E2=80=99s roadmap and philosophy.
   - Any prior work or discussion on the topic.
   - The potential scope =E2=80=94 e.g., core toolchain addition, PECL exte=
nsion,
   or standalone PHP project under the official organization.

If there=E2=80=99s interest, I=E2=80=99d be happy to draft a more formal RF=
C to outline
possible goals, structure, and implementation paths.

Thanks for reading =E2=80=94 I=E2=80=99d really appreciate your thoughts, p=
ointers to prior
work, or any guidance on how best to take this forward.

Best regards,
Dan

--0000000000000bf7f00642757488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr">Hello everyone,<br><br>I=E2=80=99d like to start a discussion abou=
t the potential for PHP to have an official Language Server, implementing t=
he Language Server Protocol (LSP) =E2=80=94 similar to what other programmi=
ng languages already provide (e.g. Go=E2=80=99s gopls, Elixir=E2=80=99s Exp=
ert, etc.).<br><br>This is not yet a formal RFC, but rather an exploration =
of whether there=E2=80=99s community interest in such a concept, and what f=
orm it could take if we agreed it=E2=80=99s worth pursuing.<br><br><b>Backg=
round / Motivation</b><br>Currently, PHP developers rely on various third-p=
arty or editor-specific language servers, including Psalm, Intelephense, an=
d phpactor. These tools are impressive, but they differ in capabilities, ma=
intenance status, and licensing (some are commercial).<br>Additionally, sev=
eral editors (e.g. VS Code, PhpStorm) implement their own non-standardized =
integrations.<br><br>By contrast, many modern languages now provide an offi=
cial language server as part of their toolchain. For example:<br><ul><li>Go=
: gopls</li><li>Elixir: Expert (official successor to the community-built E=
lixirLS)</li><li>Rust: rust-analyzer</li><li>TypeScript: TypeScript Server<=
/li></ul>These servers improve consistency, tooling integration, and access=
ibility =E2=80=94 independent of any specific IDE or vendor.<br><br><b>Why =
PHP Could Benefit</b><br><ol><li>Toolchain Completeness<br>A programming la=
nguage should ideally include its own ecosystem of core tools =E2=80=94 inc=
luding syntax checking, testing, and language intelligence.</li><li>Editor =
Independence<br>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.</li><li>Standa=
rdization<br>A unified and standardized LSP implementation would reduce fra=
gmentation and improve interoperability across IDEs and plugins.</li><li>Ac=
cessibility and Onboarding<br>Lowering the barrier for new developers by pr=
oviding consistent, out-of-the-box editor support.</li></ol><br><b>Existing=
 Building Blocks</b><br>The PHP runtime already provides components that co=
uld serve as a foundation =E2=80=94 e.g. php -l for syntax checking, reflec=
tion APIs, AST via php-ast, and insights from static analysis tools like Ps=
alm or PHPStan.<br><br>This wouldn=E2=80=99t necessarily mean rewriting exi=
sting tools, but defining a common standard =E2=80=94 potentially leveragin=
g or integrating with those efforts.<br><br><b>Next Steps</b><br>I=E2=80=99=
m not currently in a position to build such a server myself, but I=E2=80=99=
d like to open a discussion around:<br><ul><li>Whether this aligns with PHP=
=E2=80=99s roadmap and philosophy.</li><li>Any prior work or discussion on =
the topic.</li><li>The potential scope =E2=80=94 e.g., core toolchain addit=
ion, PECL extension, or standalone PHP project under the official organizat=
ion.</li></ul>If there=E2=80=99s interest, I=E2=80=99d be happy to draft a =
more formal RFC to outline possible goals, structure, and implementation pa=
ths.<br><br>Thanks for reading =E2=80=94 I=E2=80=99d really appreciate your=
 thoughts, pointers to prior work, or any guidance on how best to take this=
 forward.<br><br>Best regards,<br>Dan</div>
</div></div>

--0000000000000bf7f00642757488--