coc-prettier brings Prettier to Neovim, and it prefers your project's own Prettier

A fork of the VS Code extension, retargeted at coc.nvim

coc-prettier is a fork of the Prettier extension for Visual Studio Code, rewritten to work with coc.nvim. That lineage explains most of what the extension does and how it is configured, because the settings names, the priority model and the command surface all come from the VS Code original.

The other half of the description is what Prettier itself is, and the README puts it well: an opinionated code formatter that enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. That parse and reprint model is the point of the tool, and it is why the extension has to load a real Prettier module rather than reimplement formatting.

The language coverage is Prettier's own list, which is broad: JavaScript, TypeScript, Flow, JSX, JSON, CSS, SCSS, Less, HTML, Vue, Angular, Handlebars, Ember, Glimmer, GraphQL, Markdown and YAML, plus whatever plugins you add. The extension is written in TypeScript, the package is published to npm under the name coc-prettier with the publisher chemzqm, and the repository carries an UPSTREAM_SYNC.md file, which is the marker for a fork that tracks its origin.

Prettier comes from your project first, and the bundled copy is the fallback

The resolution order is the most consequential design decision in the extension, and it is deliberate. The extension uses Prettier from your project's local dependencies, which the README calls recommended. When prettier.resolveGlobalModules is set to true it can also try to resolve global modules on the machine. Only if Prettier is neither in the project nor installed globally does it fall back to the version bundled with the extension.

The recommended way to get the first case is to install Prettier in the project and pin its version exactly:

npm install prettier -D --save-exact

The reason to pin exactly rather than with a caret range is that the editor and the command line have to agree. If the editor formats with one version and your CI checks with another, you get diffs that only appear in CI, and the same happens between two developers with different lockfile resolutions.

There is a security prompt in the middle of this. You will be asked to confirm that the extension is allowed to load a Prettier module, and the README explains why: it is there so that you are not loading a module or script that is not trusted. Since the extension executes Prettier from a path the project controls, that confirmation is the check that the code being run is code you have approved.

Three configuration sources, with a clear priority order

The configuration story has three sources, and the README states the priority explicitly. Settings are read from the Prettier configuration file first, then from .editorconfig, and the coc.nvim configuration is ignored if any other configuration is present. If a local configuration file such as a .prettierrc exists, the coc.nvim settings are not used at all.

The recommendation in the README is worth repeating because it is a general rule and not a plugin quirk: always include a Prettier configuration file in your project specifying all the settings for the project. That way the same settings apply no matter how Prettier is run, whether from this extension, from the command line, or from another IDE with Prettier.

The coc.nvim settings file is .vim/coc-settings.json, and it is described as a fallback intended mainly for files that are not part of a project. The reason is the same consistency argument: settings applied only inside the editor produce a different result from the same file formatted elsewhere.

For a default across every project, the README points at the prettier.configPath setting, with a warning: if that value is set it is always used and local configuration files are ignored. That is a global override, and it is the setting to be careful with.

Format on save, and the fight over provider priority

Formatting on save is a coc.nvim preference rather than a Prettier one, so the extension works with the general mechanism. You enable it in the settings file, opened with the CocConfig command, by setting the format on save preference to true, and that applies to every file with a registered formatter:

{
  "coc.preferences.formatOnSave": true
}

For selected languages only, the same preference goes inside a language specific section, for example a css section or a markdown section with the preference set to true. The older format on save filetypes setting also works and takes precedence over the general one.

The interesting part is the conflict case, and the README handles it plainly. If the Prettier extension has lower priority and the document has another registered format provider, Prettier is ignored. To select coc-prettier explicitly, set the formatter extension preference to coc-prettier, which can also go inside a language specific section. To make it back off entirely, set prettier.formatterPriority to -1 so that it does not override a format provider from another extension, or disable it for specific files with a .prettierignore file or the prettier.disableLanguages setting.

The default priority of the Prettier formatter is 1, which is described as higher than another language server formatter, so out of the box Prettier wins, and you have to opt out rather than opt in.

A Vim command and a range format mapping

The extension does not require you to learn a new set of key mappings to trigger it, and the README shows the two customisations most people want.

The first is a command, set up in your init.vim or .vimrc, that formats the current buffer:

command! -nargs=0 Prettier :CocCommand prettier.forceFormatDocument

With that in place, :Prettier formats the current buffer through coc-prettier, and the CocCommand command itself opens the full command list.

The second is a range format mapping, also in init.vim or .vimrc, using the plugin's own plug mapping for a visual selection and for a normal mode range:

vmap <leader>f  <Plug>(coc-format-selected)
nmap <leader>f  <Plug>(coc-format-selected)

The languages that range format covers are the ones the extension registers, listed as javascript, javascriptreact, typescript, typescriptreact, json, graphql and handlebars.

There is also a forced format path for files Prettier would otherwise ignore, whether because of a .prettierignore entry or because they sit in an excluded location such as node_modules. The command runs a forced format on the document, and there is a related command that creates a .prettierrc for the current document.

Prettier plugins work when Prettier is resolved locally or globally

The plugin story is conditional, and the condition is worth understanding. The extension supports Prettier plugins when you are using a locally or globally resolved version of Prettier. If you have Prettier and a plugin registered in your package.json, the extension attempts to register the language and provides automatic formatting for the built-in languages and for the plugin languages.

The word attempted is doing real work there. A plugin is resolved and loaded at runtime, so a missing plugin, a plugin that fails to load or a plugin whose language the extension cannot map all end up as the language simply not being offered as formattable, rather than as an error at startup. The bundled fallback version of Prettier has no project plugins registered with it, which is another reason the project-local install is the recommended path.

The extension also exposes a document selectors setting, a list of glob patterns to register the Prettier formatter for, alongside the disable languages setting, so the set of files it claims can be narrowed per project rather than being taken wholesale.

Maintenance, packaging and where the fork sits

The package metadata describes the shape of the project. The name is coc-prettier at version 11.0.1, the entry point is lib/index.js, the package is CommonJS, and the build is a single esbuild script driven by node esbuild.js, which is also wired to the prepare script so the bundle is built on install. The lint command is tsc with no emit, and the test command runs the node test runner against the files in the test directory.

The declared engine requirement is coc 0.0.82 or newer, which is the version of coc.nvim the extension expects. The repository holds a src directory, a worker directory, a test directory, an esbuild script, a package JSON schema file, a CHANGELOG and an AGENTS.md, alongside the usual .github, .npmignore and .gitignore.

On maintenance, there are no GitHub releases and the last push was on 2026-10-03, with the repository not archived. The version number is the informative part, since it tracks the upstream VS Code extension's line, and the README has a section on the new features of 11.0.0, which added the singleAttributePerLine, jsxBracketSameLine and experimentalTernaries configuration properties. In other words, this fork moves when the upstream extension moves, and the UPSTREAM_SYNC.md file in the repository is where that relationship is documented.

Editorial conclusion

coc-prettier fits a Neovim user on coc.nvim who wants Prettier in the editor with the same settings the rest of the team uses, and who installs Prettier as a project dependency rather than relying on the bundled copy. It is the wrong tool if you are on VS Code, where the upstream extension exists, or if you want the editor to enforce a style that differs from what the project already has. Before you install it, check three things: that your coc.nvim is 0.0.82 or newer, which the package requires, that Prettier is pinned in the project with an exact version so the editor and the command line agree, and that no other extension registers a higher priority formatter for the languages you care about. The code is MIT licensed, the package version is 11.0.1, and the last push was on 2026-10-03.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. neoclide/coc-prettier on GitHub
4. README