A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/vuejs/vetur/issues/523 below:

Opt to use locally installed version of Prettier if available · Issue #523 · vuejs/vetur · GitHub

Info 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.

patrickcate, eden and lehni


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4