-
-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin support? #395
Comments
As it doesn't work, seems we would need to investigate this... Does it work if you install your plugin in |
@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 |
The minimum thing you have to pass to |
I installed the plugin into Running I restarted VSCode a few times during these experiments to make sure there's no caching effect. |
What does |
Shared some thoughts related to the Atom package: prettier/prettier-atom#395 (comment). They might map onto the VSCode extension too. |
Looks like Nevertheless, we can't say that plugins in VSCode are supported. Files with non-standard extensions (e.g. 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 |
Sadly we don't want to format any file but only files prettier supports.
I think projects would have a local copy of their prettier + plugins. |
I understand. For that reason you can call a new method called
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 |
We register a formatter in VSCode API. In our implementation, we have to know on start which language id prettier supports. 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 |
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. |
We use getSupportInfo to get all languages supported by prettier (vscodeLanguageIds). We get it in advance. We can register a formatter at any time. Maybe not when you are formatting (it will be for next format I think). |
Ideally, One question though: what to do when a workspace contains several projects, each with their own Prettier plugins and so different values in |
I don't really understand the use case for having different versions of prettier? You use it to format your code - your code doesn't depend on it? It's like I use VSCode to edit my code but my code doesn't depend on it and I don't want to install multiple versions of VSCode local to each project. The only thing I would want to be project-local is configuration. Just piping up here as a user who would love for the Python plugin to Just Work with VSCode. I have no knowledge of any technical hurdles/limitations why this might be difficult to support. My envisaged usage would be a single global prettier instance where I could install the Python plugin and then have VSCode automatically able to format Python code in all of my projects. Edit: Having just read #488 that seems a very good way forward! |
@dhirschfeld Let me explain. Two engineers working on the same project might have different global versions of prettier installed, which format slightly different. Every time they work on a file, their prettier makes those changes, leading to an endless string of meaningless git commits. This is why you absolutely want the vscode plugin to work with a locally installed prettier that is fixed to a certain version. |
@Epskampie - isn't this solved by prettier picking up the local configuration file? i.e. a project commits their prettier configuration file to their repo then all users who clone the repo will get the same configuration and prettier will use the local config in preference to any global config. i.e. you don't install a local version of the application in every repository - each repository simply has a local config which prettier uses for that repo. |
@dhirschfeld No, it isn't. The exact formatting that prettier does changes slightly for each version over time, as languages evolve and prettier evolves with it. This is normal for any code formatter, but you must take it into account. |
If you specify a configuration for the formatting of your code I'd expect that to be respected by the formatter irrespective of whatever version it was. I can appreciate that a configuration file might not imply a unique format but I'd expect changes in interpretation of the configuration to trigger a major version bump. I can also appreciate that it's not a perfect world though and things change and so I think it should be possible to install a local copy pinned to a particular version but it seems incredibly wasteful to me to require it. Personally I'd be happy to trigger (minor) formatting changes with an Anyway, just my 2c as a user - I have no insight into the code or design so take it FWIW! |
@Epskampie tooling in your editor are just nice to haves. If your team really wants to be consistent you install prettier locally and have pre commit hooks to guarantee that they use the same version. Also requiring a local version is kind of useless, if you have personal projects you want prettier but don't need all the extra dependencies. |
True, precommit hooks are also a good option. I’m not opposed to a global version also working for personal stuff by the way, but explaining why you’d want local version. If I had to choose, I’d choose local version for reasons above. |
The latest versions of I'm sharing this because the new design of |
@kachkaev's comment makes sense, hopefully something similar can be done for |
Format-on-save editor integration is crucial to make plugins useful and use Prettier in other languages like PHP |
Honestly more than anything the hamstring in VScode is only allowing one formatting extension to register itself as the provider for a certain language. You can activate two plugins that both register as the provider for say PHP but then it just comes down to a race more or less and only one can win and run during the save hook. What I have always wanted to do was figure a way to configure multiple formatting extensions for a single file type and allow a config option to set the order they run in. Also it's rough you can't be aware in the vscode gui what extensions are even running on what file types, so a ton of people end up getting two extensions that both end up registering to format X file type then it causes major user confusion because they don't know why Z extension isn't working. |
Closes prettier#395 Closes prettier#612
Sent a PR for this #757 |
Closes prettier#395 Closes prettier#612
Some good news from the SalesForce Developer Tooling team – see #890 and https://twitter.com/ntotten/status/1159830608379437056 🎉 Looking forward 🚀 |
Added with #899 |
🎉 Thank you all for making sure this works |
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. |
Hi guys,
I'm curious if there is anything missing in
prettier-vscode
to support plugins. After locally installingprettier
andprettier-plugin-elm
(which I developed myself 😃 ), the plugin works from the command line, but not in the editor. In particular, pressingoption+shift+f
while editing a markdown file, does not format```elm
code blocks. Runningyarn 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-*
innode_modules
?UPD: Same issue in prettier/prettier-atom#395 (even the same id 😄)
The text was updated successfully, but these errors were encountered: