Thorsten Ball created
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:
https://github.com/zed-industries/zed/blob/996f1036fcc86dc95f6402311175929ed3c00909/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)).crates/prettier/src/prettier.rs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -197,7 +197,7 @@ impl Prettier {
arguments: vec![prettier_server.into(), prettier_dir.as_path().into()],
env: None,
},
- Path::new("/"),
+ &prettier_dir,
None,
cx.clone(),
)