Detect Prettier module based on node_modules presence rather than package.json dep

Is your feature request related to a problem? Please describe. Yes, but bare with me this may sound a bit weird. For my companies internal stack we’re planning on distributing a shared version of Prettier (and it’s configuration) across the entire org of >700 FE repos. This is primarily an effort to reduce the overhead of managing it’s version / config / local installation, allowing us to rollout updates without sending out automated PRs to every repo.

As part of this change, the dependency will no longer be declared as a package.json dependency for these projects. However while doing so we want to ensure editor support doesn’t break, so our setup ensures the necessary directories / binaries are still included in the node_modules directory and available for use.

Describe the solution you’d like Currently it appears that the extension detects and resolves to a local version of Prettier based on finding a parent package.json with a direct dep/devDep on it.

https://github.com/prettier/prettier-vscode/blob/cd1b3aa1f40f9fb5467a2cc74c2b35d78637de03/src/ModuleResolver.ts#L298-L306

I would propose enhancing this detection to also see if a prettier binary exists at node_modules/.bin/prettier relative to any discovered package.json paths. This check could be in addition to the current check, or a replacement to it.

Describe alternatives you’ve considered The most obvious alternative here would be to specify prettierPath, but I’m hoping this could be avoided since it would need to be done in everyone’s user or workspace VSCode settings.

Additional context This appears to be how the vscode-eslint currently operates in order to find ESLint (which does work for our use case), so there is prior art in the community for this approach.

https://github.com/microsoft/vscode-eslint/blob/da0d3ce88482a14a2572b24aef75e554da6b4e66/client/src/utils.ts#L18-L27

I definitely realize that our use case is a bit non traditional, but I think the suggestion here could be a fairly general improvement to the detection of the local version of prettier. Looking at the other issues here, I think this may solve for https://github.com/prettier/prettier-vscode/issues/950 as well.

I’m happy to provide a PR for this, but wanted to run it by the team to make sure it made sense / there wasn’t any blockers to it before starting the work. Open to alternative suggestions as well!

[PinkaminaDianePie]

Is there a way to revert this behavior and check only the project root folder? That breaks my setup because I have 1.x version of prettier in some nested folder (I don’t have it explicitly, it’s a dependency of dependency) and because of that I use 1.x instead of 2.x. This implicit behavior is really weird, I have explicit 2.x in the project root, but my vscode still use 1.x because prettier check node_modules instead of package.json to resolve the path to the library.

[aju]

It should first check all package.json up to project root and then fallback