zed
zed copied to clipboard
PHP intelephense lsp setting not working!
According to intelephense docs, i want to set wordpress
stub inside intelephense.stubs
So, i just configure the editor based on zed docs :
"lsp": {
"intelephense": {
"initialization_options": {
"stubs": [
"apache",
"bcmath",
"bz2",
"calendar",
"com_dotnet",
"Core",
"ctype",
"curl",
"date",
"dba",
"dom",
"enchant",
"exif",
"FFI",
"fileinfo",
"filter",
"fpm",
"ftp",
"gd",
"gettext",
"gmp",
"hash",
"iconv",
"imap",
"intl",
"json",
"ldap",
"libxml",
"mbstring",
"meta",
"mysqli",
"oci8",
"odbc",
"openssl",
"pcntl",
"pcre",
"PDO",
"pdo_ibm",
"pdo_mysql",
"pdo_pgsql",
"pdo_sqlite",
"pgsql",
"Phar",
"posix",
"pspell",
"random",
"readline",
"Reflection",
"session",
"shmop",
"SimpleXML",
"snmp",
"soap",
"sockets",
"sodium",
"SPL",
"sqlite3",
"standard",
"superglobals",
"sysvmsg",
"sysvsem",
"sysvshm",
"tidy",
"tokenizer",
"xml",
"xmlreader",
"xmlrpc",
"xmlwriter",
"xsl",
"Zend OPcache",
"zip",
"zlib",
"wordpress"
]
}
}
}
But didn't working !!
Thanks
I would love good PHP support in Zed. People don't realise how much PHP is used.
I need support for PHP in Zed
Does anyone know zed supports intelephense premium ?
This is important for me, too. Is it a bug, or are we supposed to set the configuration in some other way?
Premium should work, although not tested by myself: https://github.com/zed-industries/zed/issues/6965
I have a similar issue, includePaths
is also not working for me. Here is the config I'm using:
"lsp": {
"intelephense": {
"initialization_options": {
"environment": {
"includePaths": ["/path/to/lib"]
}
}
}
}
braces format is also not being respected
Has anyone gotten Wordpress (and WooCommerce / ACF) stubs working in Zed?
1+
This is a horrible kludge, but I got intelephense to respect the includePaths
by directly editing one of the intelephense_data files in a private directory somewhere.
First I opened the zed log (zed: open log
) and I scanned through until I saw something like this:
2024-06-12T04:09:28-05:00 [INFO] open paths ["/private/var/folders/jk/h5pbftgn6nj_7w6rdqkqlg2w0000gq/T/intelephense/51d78cbd/intelephense_data_1"]
That file looked like this:
{"timestamp":1718183316791,"counter":{"next":1296,"holes":[]},"environment":{"documentRoot":"file:///<my wp project>“,"includePaths":[],"phpVersion":"8.3.0","shortOpenTag":false},"intelephenseVersion":"1.10.4"}
I added a couple paths to includePaths
:
{"timestamp":1718183316791,"counter":{"next":1296,"holes":[]},"environment":{"documentRoot":"file:///<my wp project>“,"includePaths":["/path/to/wordpress","/path/to/woocommerce"],"phpVersion":"8.3.0","shortOpenTag":false},"intelephenseVersion":"1.10.4"}
…then restarted zed and opened some php files with a bunch of wordpress function calls and no error messages from intelephense. Go to definition does not work, but mousing over wp function calls does show me the function’s template.
obviously there is some kind of disconnect between defining lsp.intelephense.initialization_options
in your zed settings and those initialization_options getting propagated to intelephense.
I got LSP settings working for PHP, since I needed the stub for ssh2. Basically, I had to update the zed_extension_api
for PHP to 0.0.6, and then add a fn language_server_workspace_configuration(...)
implementation which I basically grabbed from one of the other extensions. I had to build the extension using zed/crates/extension_cli
, then I bumped the PHP extension version I built so it wouldn't be replaced, and copied the built extension to .local/share/zed/extensions/installed
, I believe. I forked Zed and added my commit to my fork. After updating my PHP extension, I simply specified the stubs like so:
If anyone wants to take over from here, feel free to fork Zed, cherry-pick my commit and then create a PR.
I got LSP settings working for PHP, since I needed the stub for ssh2. Basically, I had to update the
zed_extension_api
for PHP to 0.0.6, and then add afn language_server_workspace_configuration(...)
implementation which I basically grabbed from one of the other extensions. I had to build the extension usingzed/crates/extension_cli
, then I bumped the PHP extension version I built so it wouldn't be replaced, and copied the built extension to.local/share/zed/extensions/installed
, I believe. I forked Zed and added my commit to my fork. After updating my PHP extension, I simply specified the stubs like so:If anyone wants to take over from here, feel free to fork Zed, cherry-pick my commit and then create a PR.
Could you please give a more detailed step-by-step explanation of what you had to do? I've forked Zed, installed Rust and Xcode (per these instructions), modified the files as in your commit, ran cargo build --release
, got that "target" directory, but I'm not sure what I should do next. I don't have the .local/share/zed
directory. Also, can you build just the extension? It seems that I have built the whole Zed app using that command. And how do I "bump" the extension's version? Thanks! 🙏
@federicoangelli Yeah, no problem. Basically, part of the release process, I assume is to build the extensions into a WASM plugin, and those plugins are downloaded from some plugin/release server. I think if you run Zed and install the PHP extension, you should have a ~/.local/share/zed/extensions/installed/php/
directory where the downloaded extension is placed.
Now, the tool that's actually used to build the extension (which was somewhat hard to figure out), is in crates/extension_cli
. You can build it with cargo build -p extension_cli --release
. After building the it, you can go on to build your extension like mkdir /tmp/zed_build && mkdir extension_build && ./target/release/zed-extension --source-dir extensions/php --output-dir extension_build --scratch-dir /tmp/zed_build
. For details on the arguments, you can also use ./target/release/zed-extension --help
. You should end up with a file, extension_build/archive.tar.gz
, with the extension in it. You can unpack it with cd extension_build && tar -xzvf archive.tar.gz
, and your extension should look a lot like what was present in ~/.local/share/zed/extensions/installed/php/
.
You should then edit the manifest.json file to have some version greater than 0.0.2
, such as 0.0.3
or higher, which will prevent Zed from automatically replacing your extension with the version with lesser LSP setting support.
Then, you move your built extension into the ~/.local/share/zed/extensions/installed/php/
directory, replacing the files that were currently there. You can try to do so like: cd .. && rm extension_build/archive.tar.gz && rm -rf ~/.local/share/zed/extensions/installed/php/ && cp -r extension_build ~/.local/share/zed/extensions/installed/php/
, which should move you out of the extension_build
directory, remove the archive (you can also replace it with a mv extension_build/archive.tar.gz .
if you want to keep it), remove the previously installed extension, and copy your built extension to the directory where extensions are installed. You'll also have to restart zed if you have it open.
Do note that I did all this in Linux, and the case might be different for Mac, although the biggest difference might be where the extensions are stored.
@plugd-in You're right, I've managed to make it work following your steps. On macos, the path to where extensions are installed is ~/Library/Application\ Support/Zed/extensions/installed/
, that's the only difference in our context. Thanks! 🙏
@osiewicz Any chance of getting @plugd-in’s patch incorporated into the official PHP extension so I can avoid setting up a dev environment to be able to compile Zed? 😄
v0.1.2 of the PHP extension now has support for reading the LSP settings from the Zed settings:
Here's how the settings should be structured in your settings.json
:
{
"lsp": {
"intelephense": {
"settings": {
"stubs": ["foo", "bar"],
"files": {
"maxSize": 1000001
}
}
}
}
}