Opt to use locally installed version of Prettier if available #523
Description
- I have searched through existing issues
- I have read through docs at https://vuejs.github.io/vetur/
- I have read FAQ: https://github.com/vuejs/vetur/wiki/FAQ
Info
- Platform: Win/macOS/Linux (Needs considered for each)
- Vetur version: Future
- VS Code version: Future
Proposal
Change the usage of Prettier to attempt to use the locally installed version if available. In addition, it should likely also attempt the globally installed version if a local one is not found. At that point, if there still isn't a version, then use the locally required version within Vetur. This would mimic the regular Prettier extension's behavior.
Problem
Last night a new version of Prettier was released and obviously, there hasn't been a chance to update the version Vetur currently uses, nor should it. When I was testing it out, I updated my locally installed version and found that in plain .js and .ts files it was using the newest version, but not in .vue files. I completely agree with Vetur having a fallback version and not requiring any other installation of Prettier, but if there is a local version available, I believe that should be used instead. The official Prettier documentation actually suggests locking in an exact version:
We recommend pinning an exact version of prettier in your package.json as we introduce stylistic changes in patch releases.
If Vetur maintains the version control, it isn't possible to lock in the Prettier version across a repository cloned by many users. It can also lead to some slightly unexpected behavior due to the Prettier extension functioning slightly differently when editing pure .js and .ts files. To add to a potential user's confusion, when looking at one of those js/ts files, the locally installed Prettier version appears in the bottom right corner of VS Code. It may also be a help to indicate the Vetur/Prettier version numbers on hover when looking at a .vue file.
Status
I honestly haven't even dug into the codebase yet to look at how this might be accomplished yet. I wanted to first present the suggestion to make sure there isn't a specific reason it would be a problem to implement. My guess is the logic can largely be replicated from the prettier/prettier-vscode codebase as it already functions this way.