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

[JHilker]

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!

[ntotten]

Yes, I agree this is something we should do. I haven't had time to look into it but I would love a PR!

[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]

@ntotten could you help us with solving problem that @PinkaminaDianePie mentioned ?

[JHilker]

What package are you running into that includes a transitive dependency on prettier?

[PinkaminaDianePie]

In our case it's @storybook/addon-docs, but that's irrelevant to this discussion - basically any package can have a prettier as a dependency and we have no control over it. Installing 3rd party package should not break how existing packages work.

It would be ideal to add a flag to check node_modules and put a new resolution algorithm under it while leaving the old way as a default. Otherwise, it's a breaking change in minor (patch? not sure) version, so it's not really nice. Especially that VSCode plugins updates automatically so things just breaks without any notice.

[aju]

@JHilker @ntotten maybe it could work in the way it did previously and when it does not find "prettier" in package.json it fallback to searching node_modules?
It would fix your case without breaking our setup

[JHilker]

maybe it could work in the way it did previously and when it does not find "prettier" in package.json it fallback to searching node_modules?

Yep, this is essentially what I'm already working on now. Will get a PR up today

[PinkaminaDianePie]

@aju but would it help in our case? We have a prettier as a dependency only in the repo root, but not in every subfolder, so if it will fallback to node_modules, it won't go to the repo root. We just don't know how deep should it check for package.json with explicit prettier dependency, before the fallback

package.json > explicit 2.x
subfolder
    package.json > no explicit pretier, but implicit 1.x 

how would vscode resolve a version the subfolder? It will check package.json, find out that there is no explicit prettier, so it will fallback and give us 1.x? Or we somehow know what is our actual repo root, so we will be able to go deeper exactly for 1 level, but not deeper?

[aju]

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

[PinkaminaDianePie]

No idea if it's easy or not to find the actual project root in vscode API (never did it), but if it's possible that would be a best solution

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.