Vscode-intelephense: lstat error when reading laravel project

[peterson-umoke]

started to get this error from vscode everytime i try to reindex laravel project

Please can you help?

[bmewburn]

Unusre about this one. I've seen a similar error posted on the atom repo where if a network drive is in use and gets disconnected. Do you have nodejs installed?

[peterson-umoke]

Yes, I have node js installed?

[bmewburn]

I only ask because I think vscode will use the node version that comes with electron if there is no separately installed node version. I wondered if that could make a difference.

[mtsunu]

For me, this happened because I'm running composer inside WSL. It seems that the extension can't follow symbolic link.

The workaround is running composer from windows console / git bash.

[peterson-umoke]

@mtsunu , you are actually right i do use wsl with vscode, but once i switched to git bash or cmd.exe it still doesn't works fine,, but the issue was never there before?

what changed?

[bmewburn]

The file finding was moved to the server and no longer uses the vscode file finding api available in the extension host. Now this is used - https://github.com/mrmlnc/fast-glob

[peterson-umoke]

oh.

Damn, does it support wsl?... cause i cant even use the extension with git bash or cmd.exe at all

[patrickcarlohickman]

Same problem here. When running composer inside WSL, it creates linux symlinks in the vendor/bin directory. Windows doesn't quite understand symlinks created in WSL, so running lstat from Windows (VSCode) throws an error.

I tried adding **/vendor/bin/** to the intelephense.files.exclude setting, but still got the same error. Seems like the fast-glob package is stating the files to determine if they should be excluded.

For a quick workaround for composer, you can set "bin-compat": "full" in your composer.json file, which tells composer to create Windows compatible shell scripts instead of symlinks in the vendor/bin directory. After updating the composer.json file, remove the vendor directory and reinstall (composer install).

Another workaround is to downgrade the extension in VSCode to v0.8.8.

[bmewburn]

Thanks for the workaround @patrickcarlohickman

Anyone want to write a quick nodejs script and test globbing with https://www.npmjs.com/package/glob and see if that works?

[bmewburn]

https://github.com/Microsoft/WSL/issues/1524

[peterson-umoke]

@patrickcarlohickman ... Thanks for the fix, issue resolved. Thanks so much.

[weogrim]

Same thing, when linking storage to public folder in Laraval 5.7:

php artisan storage:link

[Info - 16:47:03] Initialising [Info - 16:47:03] Reading state from c:\Users\dariu\AppData\Roaming\Code\User\workspaceStorage\352992bc5f574e91915ebc1d31678164\bmewburn.vscode-intelephense-client\4b7bd0d4. [Info - 16:47:04] Initialised in 598 ms [Info - 16:47:04] Intelephense 1.0.8 [Error - 16:47:04] Error: UNKNOWN: unknown error, lstat 'e:\firma\fbpopular\public\storage'

@patrickcarlohickman solution it is not applicable here, I think.

[patrickcarlohickman]

@weogrim Yeah, the composer stuff I mentioned won't help you out at all in this scenario. You can try making the link in windows, and hope WSL knows how to read it properly.

If you have php installed on your windows host, you can run php artisan storage:link from windows (not using WSL), and it will create the windows link. However, if you're like me, and use WSL to avoid having to install dev tools, this may not be an option.

If you don't have php installed and don't want to install it, you can run the mklink command yourself from a windows command prompt (adjust the paths as necessary).

mklink /J "e:\firma\fbpopular\public\storage" "e:\firma\fbpopular\storage\app\public"

This is the underlying command that php artisan storage:link would run. The /J option tells windows to create a hard link (directory junction). If WSL can't understand this, you can try using /D to create a soft link.

If creating the link in Windows does't resolve the issue, I think your only recourse would be to downgrade the extension to v0.8.8.

[marveloo]

I have found the best workaround is to enable "Developer mode" on Windows. From then on all newly created symlinks on WSL will be real symbolic links and not junctions.