Ale: PHP Intelephense crashes, bug in setting up Initialization Options

[creativenull]

Information

VIM version
NVIM v0.4.3
Build type: Release

Operating System:
Ubuntu 20.04.1 LTS

What went wrong

GetInitializationOptions requires a buffer argument that wasn't provided. This is probably a breaking change, since the initial PR #3357 was written 2 months ago.

I will create another PR for this fix. This issue is just to track that.

Reproducing the bug

1. Open any PHP file.
2. Then this happened.
   

[ngtinsmith]

Okay, so adding the fix from the fork seems to work, but for some reason, stubs are now undetected (e.g, wordpress) so lot's of core functions defined in the stubs like add_action, is_user_logged_in, get_post_meta, etc. are now showing as undefined even though vim.lsp.buf.definition works fine (I can see the function signatures from the stub).

I have the stubs defined like this (this was working prior to my recent update):

local lsp = require'lspconfig'
local util = require 'lspconfig/util'

lsp.intelephense.setup {
  settings = {
    intelephense = {
      stubs = {
        -- ... other stubs
        "wordpress",
      }
   },
   root_dir = util.root_pattern("header.php", "package.json", "style.css")
}

Edit: Managed to narrow down the issue to only occur when we use intelephense as an option for ale_linters. We can check this through :ALEInfo and see the list of enabled linters.

The use of intelephense as linter happens _implicitly_ if we don't set any specific php linter so I had to pass a set excluding intelephense into the global g:ale_linter var, and stubs are now detected normally, or at least the the undefined linting of stub related functions are now gone.

I'm using this now if anyone encounters the same issue:

let g:ale_linters = { 'php': ['php'] }

[creativenull]

Intelephense should work out of box without adding any specific stubs. If you open a wordpress project then it will index all files within the project directory. I haven't had the use of adding any specific stubs that way. I also have nvim-lsp setup on another config and seemed to work fine without adding stubs.

On addition of your edited message, I would recommend to set linters explicitly, that way you can control which linters you want enabled. Here is one example of setting only intelephense as the only linter if a php file is opened in a buffer:

let g:ale_linters_explicit = 1
let g:ale_linters = {
\ 'php': ['intelephense'],
\ }

If you're interested I can add my ALE config and nvim-lsp config for intelephense below. Try that and let me know if you still get any issues with it.

ALE Config

nvim-lsp Config

[ngtinsmith]

Yeah, it's still not working for me, still flags wordpress as well as custom symbols as undefined whenever I add intelephense to the ale_linters array. Thanks for the reference configs though, I'll be sure to review this more later.

Unfortunately, I've already spent some amount of time on this so I'm not gonna pursue this further for now as I need to get to some work done. I was able to make it detect local symbols though (not those from wordpress) so indexing is working properly now. :+1: , I had to install it locally and point to that executable like so:

lua.intelephense.setup {
  cmd = { './node_modules/.bin/intelephense', '--stdio' },
  settings = {
    -- ... same as my original settings
  },
}

You were right that stubs are enabled by default but not all of them are as defined in the docs here.

For example if you expand the intelephense.stubs config, you can see that wordpress is not included in the default stubs array so I have to include it manually for my use case, still the case for me is that I NEED to include a bunch of those stubs manually since even native php functions are not being detected (i.e, json_encode, glob, etc.) if I don't.

At this point, I'm not sure how exactly are these stubs resolved since we can define a custom intelephense config on both nvim-lspconfig as well as on g:ale_php_intelephense_config and even use a custom executable which makes me think that indexing won't work depending on the resolved workspace in relation to the executable being used, global or local.

Anyway, I'm not gonna waste more time chasing this unicorn as what I have now is working for my use case (completion, lsp/symbol suggestions, static/public method linting, etc.) so I'm gonna keep this setup for a while.

I appreciate your help nonetheless. :+1:

[creativenull]

No worries 🙂! I just wanted to add, in contrast to the nvim-lsp config you've shown, that intelephense config for ALE requires that you have intelephense installed globally and not on a project-level basis (This can be changed in g:ale_php_intelephense_executable). But you can have a look at this at your own leisure.

g:ale_php_intelephense_config is intended for the initialization options that is described in their intelephense docs. So not where you will add the stubs per se, it's not very clear in the docs, but I'll research it out end of the week.