Future tooling plans?
cweagans opened this issue · 4 comments
Not sure if you're at liberty to discuss at this point, but related to #36 (comment), I was wondering if you had future plans in the PHP tooling space. Will you be building an "official" language server on top of this parser for vscode (or other LSP clients)? Tooling for PHP devs that use vim (or similar) is just abysmal at this point, and it would be awesome to be able to be reasonably productive in vim again!
Hey @cweagans, good question! I'm totally at liberty to discuss, but I don't know if I have a very good answer for you just yet.
Like I said before, ultimately our goal is to ensure that VS Code (and, by extension, other LSP clients) have amazing PHP tooling, and we've learned (the hard way) that a parser that is fast + memory-efficient, provides graceful error-handling, and produces fully-representative trees is critical to this experience.
Overall, we've been extremely energized by the amazing reception from the community, both in the form of social media (twitter/reddit), and all the awesome contributors here on GitHub. (THANK YOU!)
So how exactly will this all pan out? It's a bit early to tell. Y'know that "Kinect Effect" Ad from a while ago? Well to steal a line from that... "Even though the world keeps asking us what we'll to do with tolerant-php-parser next, we're just as excited to ask the world the same thing." 😉
In that vein, we're currently taking a two-pronged approach:
- Provider: continue filling in the gaps on the parser itself identified from both our validation tests, and community feedback.
- Consumer: we've laid a solid foundation, and we're excited to partner w/ folks and see where the community takes it next (whether it be a VS Code extension, or something else). This will help us prioritize our backlog, and also shape the API. If you're interested, but have some questions or blocking issues, please reach out and we'll see how we can help.
That was an excellent ad. I'd never seen that one before you linked to it!
I've been keeping an eye on the PHP tooling space for a while and while there aren't a lot of good options at this point, there's no reason there can't be (especially with this new parser). Frankly, my goal is to get to the point where there's a plugin like https://github.com/fatih/vim-go, but for PHP. That plugin obviously relies on a lot of external tooling that supports refactoring, code completion, linting, static analysis, etc., but if it can be done in vim, it can be done anywhere.
My hope is that as you work toward amazing tooling for vscode, it'll be built in such a way that can be consumed by any editor and not just vscode. It would be a real game changer for me, and frankly, I'd happily spend a significant amount of time contributing to that effort if there was some direction on what needs done.
This is a great question!
My suggestion, as an early adopter of vscode that missed php integration & intellisense, is to get the help/opinion of the two great guys who developed the biggest extensions for php.
So, I invite @felixfbecker, @nevadascout (HvyIndustries/crane) & maybe @ichiriac, maintainer of glayzzle/php-parser to this discussion.
Personally I use Felix extension now & I'm missing every day go-to-definition on comments & var-doc, which apparently is a limitation of phpDocumentor, the details are here: felixfbecker/php-language-server#134
Unfortunately I can't give more details, but as a PHP developer I would love to contribute to a future-proof way of complete PHP Intellisense solution. Having those efforts split just to have full control of the project seems like it's beyond the values of open source (for example HvyIndustries/crane#141).
Thank you!
https://github.com/phan/phan/wiki/Editor-Support#editors-with-phan-support provides improved static analysis. Unfortunately, it currently requires unix/Linux (due to requiring php (EDIT: works even without pcntl now)pcntl) (This is a language server added to a static analyzer)
- It uses tolerant-php-parser as a fallback to parse invalid ASTs while the user is typing
- Pcntl might be possible to avoid in the future if the complete state can be saved and restored (entirely in php) instead of using pcntl forking.
Tooling for PHP devs that use vim (or similar) is just abysmal at this point, and it would be awesome to be able to be reasonably productive in vim again!
https://github.com/autozimu/LanguageClient-neovim exists (it supports neovim, and I think it supports vim 8), and has plugins for felixfbecker/php-language-server and Phan