Plugin support?

[kachkaev]

Hi guys,

I'm curious if there is anything missing in prettier-vscode to support plugins. After locally installing prettier and prettier-plugin-elm (which I developed myself 😃 ), the plugin works from the command line, but not in the editor. In particular, pressing option+shift+f while editing a markdown file, does not format ```elm code blocks. Running yarn prettier same-file.md from the terminal does this job perfectly.

What could be causing the issue? Can it be that the way prettier is spawned does not let it search for prettier-plugin-* in node_modules?

UPD: Same issue in prettier/prettier-atom#395 (even the same id 😄)

[CiGit]

As it doesn't work, seems we would need to investigate this...
We would need to understand how those plugins are listed by prettier. I think it has something to do with cwd()

Does it work if you install your plugin in $HOME/.vscode/extensions/esbenp.prettier-vscode[VERSION]

[kachkaev]

@CiGit when a code is being sent to Prettier by the extension, is it only a text or the metadata too? My conversation with @olsonpm regarding the same issue in Atom plugin suggests that Prettier may be picking a default language instead of markdown/elm/etc. and silently fails because the given code is not parsable. Can this be the case?

UPD: Probably not, since markdown itself gets parsed. Must be something to do with cwd 🤔

[CiGit]

The minimum thing you have to pass to prettier.format is text and a parser if it's not JS. Seems we can also pass filepath for parser inference.

[kachkaev]

I installed the plugin into /Users/ak/.vscode/extensions/esbenp.prettier-vscode-1.2.2/node_modules/prettier-plugin-elm/ – still no effect. Also tried deleting local prettier and prettier-plugin-elm to fallback to the extension's instance, no effect either.

Running npm install -g prettier prettier-plugin-elm did not help as well. In all cases markdown gets formatted, but a fenced ```elm blocks do not.

I restarted VSCode a few times during these experiments to make sure there's no caching effect.

[kachkaev]

What does prettier.getSupportInfo() just before you call prettier.format(...)? Does it list languages from the plugins when these are installed?

[kachkaev]

Shared some thoughts related to the Atom package: prettier/prettier-atom#395 (comment). They might map onto the VSCode extension too.

[kachkaev]

Looks like prettier-vscode will partially work with plugins after they release Prettier 1.13 – I could test this by locally installing a beta version together with prettier-plugin-elm. Finally, formatting markdown files prettifies Elm code blocks in them too! I believe that this change in behaviour is related to prettier/prettier#4000, which is now closed.

Nevertheless, we can't say that plugins in VSCode are supported. Files with non-standard extensions (e.g. .elm or .php) are still not picked by vscode-prettier, which means that plugins only come into play in markdown code blocks 😕 A new method called getFileInfo() that is being introduced in 1.13 should be a solution here. This method can be called before an attempt to format any file and if the value of inferredParser returned is not null, then call format() (either with the just derived value for parser or by giving it a file path).

Another thing that's missing is falling back to a global Prettier if the local one is not found. The global copy can have some plugins installed, which is never the case for the built-in instance. See #232 (comment) for more details. I expect the use of a global Prettier with plugins to be pretty common, because not all people would not want to call npm install in PHP, Python, Java or Elm projects.

[CiGit]

This method can be called before an attempt to format any file and if the value of inferredParser returned is not null, then call format() (either with the just derived value for parser or by giving it a file path).

Sadly we don't want to format any file but only files prettier supports.

I expect the use of a global Prettier with plugins to be pretty common, because not all people would not want to call npm install in PHP, Python, Java or Elm projects.

I think projects would have a local copy of their prettier + plugins.
You would not be able to have prettier@v1 + plugin-L1 in project A and prettier@v2 + plugin-L2 in project B on the same machine (vm)

[kachkaev]

Sadly we don't want to format any file but only files prettier supports.

I understand. For that reason you can call a new method called getFileInfo() for any file and thus figure out if it's supported by the current instance of Prettier (given the plugins) or not.

I think projects would have a local copy of their prettier + plugins.
You would not be able to have prettier@v1 + plugin-L1 in project A and prettier@v2 + plugin-L2 in project B on the same machine (vm)

It'd be great if this could be avoided. Picking different plugins should be possible with the new API, no matter if you use Prettier as a node module or as a spawned CLI tool. Ideally, each project should be using its own instance of Prettier to avoid unexpected mismatch between what's happening in the editor and in CI later on. Depending on what pluginSearchDirs you pass to Prettier, different plugins can be loaded (see upcoming docs). Using a global copy of Prettier is what may non-JS users would want (e.g. PHP users, prettier/plugin-php#416).

[CiGit]

I understand. For that reason you can call a new method called getFileInfo() for any file and thus figure out if it's supported by the current instance of Prettier (given the plugins) or not.

We register a formatter in VSCode API. In our implementation, we have to know on start which language id prettier supports.
If we would register a formatter for everything, other formatter would have trouble. even for languages prettier doesn't support.

You can't use a global copy if your projectS rely on a specific version (be it prettier or a plugin).

I don't see how useful pluginSearchDirs is. I would certainly install plugins alongside prettier and use plugin's auto-search feature.

[kachkaev]

We register a formatter in VSCode API.

Can we do this dynamically (both in time and between projects)? If not, it might be worth opening an issue in VSCode to allow this.

Prettier does support an open list of languages and since recently, and this list cannot be derived in advance. Therefore, if VSCode does not know how to deal with it, it should learn to :–) Simply not doing what users will be expecting after installing Prettier plugins locally and globally does not look like the way to go. I'm sure the solution exists, it's just a matter of how many symbols in the equation we should change.