### Issue
So this pull request fixes an issue that was driven me crazy. The issue
was that when you use the `prettier-plugin-organize-imports` It would
remove some imports that should not be removed before they were used
inside the module itself.
You can reproduce it with the following `prettierrc.json` config and
source code. When you **save** the file, it would remove the `import
clsx from "clsx";` import from the file.
**Prettier config**
```json
{
"semi": true,
"tabWidth": 4,
"trailingComma": "es5",
"useTabs": true,
"plugins": [
"prettier-plugin-tailwindcss",
"prettier-plugin-organize-imports"
]
}
```
**Source code**
```typescript
import clsx from "clsx";
export default function Home() {
return (
<main>
{clsx("asdjklasdjlkasd", "asdjlkasjdjlk")}
</main>
);
}
```
### Findings
After a deep dive with @mrnugget, I was debugging deep down the prettier
plugin system and found the issue that was causing this issue. When I
was looking inside the
`node_modules/prettier-plugin-organize-imports/lib/organize.js`. I saw
the following code that looked strange to me because it falls back to
`file.ts` if `filepath` is not passed through inside the prettier config
options.
<img width="860" alt="Screenshot 2024-03-20 at 21 31 46"
src="https://github.com/zed-industries/zed/assets/62463826/47177fe5-e5a9-41d8-9f2f-0304b2c2159f">
So the issue was small, if you look at the following code, the `path`
key should be `filepath` inside the
`crates/prettier/src/prettier_server.js:205`
![Screenshot 2024-03-20 at 21 35
25](https://github.com/zed-industries/zed/assets/62463826/1eea0a88-c886-4632-9c69-9f3095126971)
Release Notes:
- Fixed prettier integration not using the correct filepath when
invoking prettier, which could lead to some prettier plugins failing to
format correctly.
([#9496](https://github.com/zed-industries/zed/issues/9496)).
Our goal is to extract Svelte support into an extension, since we've
seen problems with the Tree-sitter Svelte parser crashing due to bugs in
the external scanner. In order to do this, we need a couple more
capabilities in LSP extensions:
* [x] `initialization_options` - programmatically controlling the JSON
initialization params sent to the language server
* [x] `prettier_plugins` - statically specifying a list of prettier
plugins that apply for a given language.
* [x] `npm_install_package`
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PURELY formats the file by opening it in Zed and hitting save with
save-on-format on.
It's been bugging me that I can't change the file without the whole
thing getting reformatted, so here we are.
Release Notes:
- N/A
This fixed the issue that prettier plugins were not picked up. The old
code would always send an empty array to the prettier plugin that
happens inside the `prettier_server.js`.
**Before**
The `options.plugins` key is an empty array, which is not correct.
```log
stderr: Resolved config: {"singleQuote":true,"trailingComma":"all","plugins":["prettier-plugin-organize-imports"]}, will format file '/Users/remcosmits/Documents/code/prettier-test/src/app/page.tsx' with options: {"singleQuote":true,"trailingComma":"all","plugins":[],"parser":"typescript","path":"/Users/remcosmits/Documents/code/prettier-test/src/app/page.tsx"}
```
https://github.com/zed-industries/zed/assets/62463826/52f2aad0-2f96-43a9-81ec-9d4630c495b2
**After**
The `options.plugins` contains the `prettier-plugin-organize-imports`
plugin as expected.
```log
stderr: Resolved config: {"singleQuote":true,"trailingComma":"all","plugins":["prettier-plugin-organize-imports"]}, will format file '/Users/remcosmits/Documents/code/prettier-test/src/app/page.tsx' with options: {"singleQuote":true,"trailingComma":"all","plugins":["prettier-plugin-organize-imports"],"parser":"typescript","path":"/Users/remcosmits/Documents/code/prettier-test/src/app/page.tsx"}
```
https://github.com/zed-industries/zed/assets/62463826/9045028d-aeca-4df1-819c-01905d83216c
Release Notes:
- Fixed send plugins correctly to the prettier plugin
([#8841](https://github.com/zed-industries/zed/issues/8841)).
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
This fixes#8823 by setting the current working directory we use when
launching our own `prettier` process via `node` to the project path.
Why does this fix it?
We already *did* read the correct configuration options for `prettier`
from any configuration files, we also correctly inferred which
`prettier` plugins to use, but somehow when running
./node_modules/.bin/prettier my-file.tsx
produced different results compared to `prettier` in Zed.
But we *do* pass the right options to `prettier.format` when calling it
here:
996f1036fc/crates/prettier/src/prettier_server.js (L177-L190)
I checked those against the `prettier --loglevel=debug` output: they're
the same.
Turns out that the difference is we launch our `prettier_server.js` (a
JavaScript shim that wraps `prettier`-the-library in a language server
interface) not in the project path.
So somewhere inside `prettier.format` something is `require`d and fails
because we're not in that project directory. But when you run
`./node_modules/.bin/prettier` you are.
With the fix here, `prettier` now correctly picks up the tailwind plugin
that didn't seem to work in #8823. It probably fixes a bunch of other
oddities that folks reported with `prettier` too.
Release Notes:
- Fixed `prettier` integration not correctly picking up `prettier`
plugins, because it didn't run in the project's root path when invoked.
([#8823](https://github.com/zed-industries/zed/issues/8823)).
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
After a lot of back-and-forth, this is a small attempt to implement
solutions (1) and (3) in
https://github.com/zed-industries/zed/issues/7902. The goal is to have a
minimal change that helps users get started with Zed, until we have
extensions ready.
Release Notes:
- Added detection of user-installed `gopls` to Go language server
adapter. If a user has `gopls` in `$PATH` when opening a worktree, it
will be used.
- Added detection of user-installed `zls` to Zig language server
adapter. If a user has `zls` in `$PATH` when opening a worktree, it will
be used.
Example:
I don't have `go` installed globally, but I do have `gopls`:
```
~ $ which go
go not found
~ $ which gopls
/Users/thorstenball/code/go/bin/gopls
```
But I do have `go` in a project's directory:
```
~/tmp/go-testing φ which go
/Users/thorstenball/.local/share/mise/installs/go/1.21.5/go/bin/go
~/tmp/go-testing φ which gopls
/Users/thorstenball/code/go/bin/gopls
```
With current Zed when I run `zed ~/tmp/go-testing`, I'd get the dreaded
error:
![screenshot-2024-02-23-11 14
08@2x](https://github.com/zed-industries/zed/assets/1185253/822ea59b-c63e-4102-a50e-75501cc4e0e3)
But with the changes in this PR, it works:
```
[2024-02-23T11:14:42+01:00 INFO language::language_registry] starting language server "gopls", path: "/Users/thorstenball/tmp/go-testing", id: 1
[2024-02-23T11:14:42+01:00 INFO language::language_registry] found user-installed language server for Go. path: "/Users/thorstenball/code/go/bin/gopls", arguments: ["-mode=stdio"]
[2024-02-23T11:14:42+01:00 INFO lsp] starting language server. binary path: "/Users/thorstenball/code/go/bin/gopls", working directory: "/Users/thorstenball/tmp/go-testing", args: ["-mode=stdio"]
```
---------
Co-authored-by: Antonio <antonio@zed.dev>
Current prettier support w/i Zed leaves out a few languages that are
officially supported by prettier. In particular, Vue and Markdown are
supported by the core prettier project, and PHP is supported via an
official plugin. I didn't see any open issues for this, but I have been
wondering for months why `"formatter": "prettier"` wasn't working on my
PHP files. Now that Zed is open source, I was able to find out why, and
fix it. 😄
I have been using this with PHP files daily for a week+ now, and I have
also used it successfully with Vue and Markdown files, though not as
extensively. I looked around and did not see any tests for specific
prettier language integrations, but if I missed them please let me know
and I'll add some tests.
**Notes**
- I did not add support for Ruby (which has an official prettier plugin)
because it seems to require some external dependencies (notably, Rudy
and some Gems). When those are present on the system and `$PATH`,
prettier will will work just fine on Ruby files if the plugin is set up
similar to how the PHP plugin is set up (I tried it), and I can add that
in here, if desired. The PHP plugin is pure JS (as I recall) and doesn't
have this issue.
- I did *not* add support for languages that have "community" plugins,
though I do note that Zed already ships with prettier support for svelte
enabled, which – if I understand correctly – is powered by a community
plugin. If desired, I could look at adding support/configuration to
enable prettier support for things like elm, erb, glsl, bash, toml.
Bash, in particular, *I* would find useful. 😄
Release Notes:
- Added prettier support for Vue, Markdown and PHP
Based on the great work in
https://github.com/zed-industries/zed/pull/7130 , now sends this data
```
[crates/lsp/src/lsp.rs:588] ClientInfo { name: name.to_string(), version: Some(version.to_string()) } = ClientInfo {
name: "Zed Dev",
version: Some(
"0.122.0",
),
}
```
with every LSP server initialization.
Release Notes:
- Added Zed name and version to LSP InitializeParams requests
This PR sorts the dependency lists in our `Cargo.toml` files so that
they are in alphabetical order.
This should make them easier to visually scan when looking for a
dependency.
Apologies in advance for any merge conflicts 🙈
Release Notes:
- N/A
- [x] Fill in GPL license text.
- [x] live_kit_client depends on live_kit_server as non-dev dependency,
even though it seems to only be used for tests. Is that an issue?
Release Notes:
- N/A