New maintainers for php-language-server?

[Ciantic]

This is a stretch, since I'm not suggesting myself as a maintainer. But there are companies and contributors in PHP-community building awesome tools and working hard. E.g.

https://github.com/vimeo/psalm/graphs/contributors where @muglug is building huge tooling around psalm and https://github.com/phpstan/phpstan/graphs/contributors where @ondrejmirtes is building phpstan.

I wonder, what do people use for your IDE? I wish there were more concentrated effort in this area.

I think the psalm and phpstan has both code that are important for great IDE effort. Static analysis is exactly what is required for IDE to discover the code e.g. intellisense etc.

[muglug]

@Ciantic I'm afraid I'd have to decline. While Psalm has benefited from the work @felixfbecker has done (Psalm has some language server support built-in) I don't have time to take on maintenership of this project.

More broadly, PHP has an issue with tooling: while it has millions of users, the percentage of those able to create good-quality language tools is very small (vs a language like Rust that has very few users, but a much larger percentage who can write good-quality tools).

While that means there's money to be made by those few tool creators (think Intelliphense, PHPStorm etc.), it also means there's much more pressure on open-source maintainers than is found with more complex languages.

[felixfbecker]

More broadly, PHP has an issue with tooling: while it has millions of users, the percentage of those able to create good-quality language tools is very small (vs a language like Rust that has very few users, but a much larger percentage who can write good-quality tools).

While that means there's money to be made by those few tool creators (think Intelliphense, PHPStorm etc.), it also means there's much more pressure on open-source maintainers than is found with more complex languages.

Truer words have not been spoken 😞

[Ciantic]

Thanks for your answer. I don't care what the language server is called, if the language server inside psalm seeks to implement IDE tooling it would be just as fine, but having multiple efforts is the problem here. I feel like people are building same tooling in their own silos, with slightly different API etc.

I read psalm language server states this:

It currently supports diagnostics (i.e. finding errors and warnings), go-to-definition and hover.

Which is interesting. I don't mind if you are building one already! Maybe it will sunset this one some day. Same thing applies to phpstan, since it tries to make static analysis tools.

P.S. and I think the contribution graphs of phpstan and psalm make me feel like you have combined knowledge to build a IDE-tooling.

[muglug]

Building a good type inference engine capable of finding bugs (the primary aim of Psalm, PHPStan and others) and building a language server that makes writing code more convenient (the goal of this and other similar tools) are two fairly different tasks — you can’t just plug one into the other.

It took a couple of months of work to get Psalm ready to be used as a language server, and it’s still not particularly featureful (though Psalm does now also LSP completion events).

One big reason: PHPStorm. It means that most people who use Psalm will never use its language server, which means there are even fewer Psalm users to ticket and/or fix the bugs that the language server has.

[Gert-dev]

Hi, I also wanted to chime in, since I'm also active in the same area. You may remember me from #108, where we discussed working together and I mentioned that I didn't know if I would have the time to rewrite Serenata (php-integrator back then) as an LSP. I did do that since then, but only a good while later. I forgot to come back to this discussion later, sorry for that. Someone on Serenata's issue tracker put me on this discussion, which is why I wanted to chime in.

I can confirm that writing a language server and static analyzer are two different tasks. Tools such as PHPStan - I'm using it as an example since I have some experience with it - have different constraints; i.e. if an analysis takes a second longer or not is of little consequence to most users in a typical scenario, whilst the same is almost unacceptable for a language server, as low latency is a concern to keep the workflow for users responsive. PHPStan also, AFAIK, still requires executing the code it analyses, which is a security concern, especially for a language server that may run in remote scenarios.

In the case of PHPStan I've tried to indirectly work together by reusing parts of it as a good static analyzer is a lot of work in itself [1]. PHPStan has not had a major release yet, so their API is still seen as unstable, which makes keeping up painful for a project such as mine (which is mostly a one-man show). (On a related note, I did recently partially switch to PHPStan's docblock analyzer.)

It may also be worth mentioning that a PHPStan language server - separate from the main project - exists. The idea sounds great, since the foundation PHPStan provides for static analysis is solid, but things such as performance create additional challenges due to the issues mentioned above. I sometimes wonder if it's easier to integrate something like Psalm or PHPStan in an existing language server or to cease my activities and build a new language server around those tools instead.

I concur with the fact that many developers use PhpStorm and are not interested in a separate language server. I think there is also an opportunity, here, though, since I noticed that PhpStorm has been running behind on the advanced analysis that tools such as Psalm and PHPStan offer (I'm thinking of generics via docblocks, advanced null checks, and so on). An open language server that also offers these, will make it easier for developers to adhere to the stricter constraints that these tools enforce and that all from the comfort of your editor of choice instead of being stuck with a JetBrains IDE.

(In case anyone's wondering, I didn't put a link to my project here out of respect, my intention is not to be a vulture hovering over a project on life support.)

[1] https://github.com/phpstan/phpstan/issues/420

[ondrejmirtes]

still requires executing the code it analyses

BTW This will mostly cease to be true in a week or so as I release a new version (0.12.26) that uses mostly static reflection. See this comment for more details: https://github.com/phpstan/phpstan/issues/67#issuecomment-632362615

[jens1o]

@felixfbecker Could you please elaborate on what the current maintenance status is here? Would you review and accept PRs?