Plugin API not working with globally installed modules

[czosel]

Currently, globally installed plugins don't seem to be discovered by the CLI:

npm install -g prettier @prettier/plugin-php
prettier --plugin=@prettier/plugin-php --parser=php test.php
# Error: Cannot find module '@prettier/plugin-php'

npm init --yes
npm install prettier @prettier/plugin-php
prettier --plugin=@prettier/plugin-php --parser=php test.php
# works

It seems that read-pkg-up is just looking for the closest package.json file, which doesn't work for global installs

prettier/src/common/load-plugins.js

Line 4 in 1b61b81

const readPkgUp = require("read-pkg-up");

(in case you're wondering why i'm explicitly passing the plugin: There also seems to be an issue with automatic discovery, running the command without results in SyntaxError: Unexpected token (see prettier/plugin-php#55))

[ikatyang]

One solution is to set cwd to its own directory instead of process.cwd(), but I'm not sure if there's a side effect.

prettier/src/common/load-plugins.js

Lines 22 to 24 in 1b61b81

	readPkgUp.sync({
	normalize: false
	}).pkg

[kachkaev]

@ikatyang looks like you're right – changing cwd helps indeed. I implemented a quick patch with this change to check your theory and was able to get Prettier plugins working inside Atom and VScode extensions (prettier/prettier-atom#395 and prettier/prettier-vscode#395) when the plugins are locally installed project dependencies.

Searching for packages in a globally installed Prettier is still not working because there is no package.json in /usr/local/lib/ (where my global node_modules are on macOS). It feels like if Prettier was searching for prettier-plugin-*/@prettier/plugin-* folders in parent node_modules rather than checking package.json, we could get a more universal solution, which would work for both local and global setups. What is also good about this approach is that plugins will be pickable when they are a part of some boilerplate packages like create-react-app. Their philosophy is to give a project creator all they want with just a single dependency in package.json.

When basedir in my hacky patch is set to process.cwd(), it equals to /path/to/current/folder for global Prettier being executed from the command line. For some reason, it is equal to / inside Atom package.

I really wish I could submit a proper PR with a fix, but after spending a couple of hours on getting to where I am, I have to admit that I won't be able to lift it. Sorry for that and hope that my experiments help you with a proper fix! Happy to try something else if that's useful.

[ntkoopman]

This also breaks on non global installs when you invoke prettier from a parent directory.

[kachkaev]

@azz WDYT of searching plugins by scanning dirs in node_modules rather than the contents of package.json? See the above comments as context.

Pinging you as the author of #3536 and #3624 😉

[azz]

I think it's an ok solution. The use case I was originally trying to avoid was where plugins could be loaded unexpectedly (due to being intalled via transitive deps), and thus not having a way to opt out of these plugins being loaded.

I wonder how parcel bundler handles this?

[kachkaev]

IMO supporting transitive deps is a nice feature, not a thing to avoid – it'll be useful in tools similar to create-react-app. Glad that you also don't mind them (if I understood you correctly)!

I never used parcel, so unfortunately don't know how to help with your question. Who would be a good candidate for trying to submit a PR in your opinion? 🙏

[kachkaev]

Looks like I was able to fix this in #4192! 🎉 Parcel bundler seems to be OK with all this – at least yarn test:dist passes.

[kachkaev]

For those who can't wait to use prettier plugins globally while #4192 is being discussed, feel free to use a custom build derived from that PR:

npm install --global \
  github:kachkaev/prettier#5e308113217638949cc6047527d0999fe4a30de6 \
  @prettier/plugin-a \
  prettier-plugin-b

cd /any/folder
prettier '**/*.(a,b)'

This partially worked for me in prettier-atom and atom-mprettier after telling these plugins to use a global instance of Prettier. The plugins began to format code blocks in custom languages inside markdown files (more specifically, I formatted Elm code blocks via prettier-plugin-elm).

Formatting of *.a and *.b via editor extensions is not yet supported (e.g. see prettier/prettier-atom#395 and prettier/prettier-vscode#395)

[j-f1]

Shorter install name: kachkaev/prettier#fix-global-plugin-api

[kachkaev]

Or kachkaev/prettier#fix-global-plugin-api-dist (with -dist in the end) – this is the same as 5e308113217638949cc6047527d0999fe4a30de6 mentioned two comments above.

In this case the package only has pre-built files and works better in editor plugins. The sources in fix-global-plugin-api branch contain eval("require") statements, which work pretty badly in Atom (#1895).