Code formatting is often taken for granted in most languages. But it is not so easy to make a good formatter.
Back in the days of Adobe Flex, I remember someone in Brazil wrote a brilliant plugin for Eclipse that had an option for literally everything. It was amazing, you could customize the decisions for every possible thing you could imagine and then export or import the settings so that it could be shared across the team.
If you introduce something like JSX or Vue.js it gets even more complicated. Consider a file like the following in Vue.js:
<template> ... </template> <script> ... <script> <style> ... </style>
So what we end up with for something like Vue.js is a complex scenario where you cannot just install a "code formatter", you would need to specify dozens of options. And if the formatter runs into some lines of code that are using an obscure rule in the Babel transpiler, like asynchronous imports, the standard syntax is not what it expects.
Typically a good formatter will use a parser to build up an AST (abstract syntax tree) of the code, and then pass the AST back through the formatter to output new text. However, this means that the formatter would need to have access to the AST for Babel, for example. This might be available to some extent, but it also means that potentially the formatter would need to know all of the options specified in various configuration files (e.g. Webpack + package.json + babelrc). It could offload this to the Babel transpiler, but I have not dug into this enough to know how much access they provide to third parties that do not intend to actually transpile the code.
Not to mention, there are obscure bugs in Prettier that I have found that make it especially difficult when working with JSX or Vue.js templates. In some cases, people on Stack Overflow have even suggested just abandoning Prettier because some of the bugs have been dormant for over 4 years without a fix in sight. There are workarounds, but quite frankly at this point one has to wonder whether it would just be faster to avoid a formatter at all rather than fighting issues like this.
JSLint and Others
There are a few other options, but from what I have seen they are not maintained well. JSLint was apparently abandoned in favor of ESLint - or merged in. Not sure of the history. But in any case, it would be a sad state of affairs to adapt a codebase to a poorly maintainted formatter.