Formatting is done by js-beautify, the same library that sits behind the reformat command in a great many editors, vendored locally rather than fetched from anywhere. Three modes are available — JavaScript, HTML and CSS — and they are genuinely different parsers rather than one routine with a switch, which is why choosing the wrong one produces obviously wrong indentation rather than a subtle mistake.
Indentation is yours to set, in spaces or tabs. Existing blank lines are preserved up to a limit of two consecutive, so the deliberate spacing between functions survives while accidental runs are tidied away. Line wrapping is left off, since a hard wrap column tends to fight with whatever the project already does.
What formatting does and does not fix
-
It reformats, it does not rewrite:
no variable is renamed, no statement reordered and no logic touched. Code that was wrong before is wrong afterwards, laid out more clearly.
-
Choose the mode to match the file, not the extension:
a template file full of markup wants the HTML mode even when its name suggests otherwise, and JavaScript embedded in a page is formatted by the HTML mode along with everything around it.
-
It is not a linter:
nothing is checked. Code that cannot be parsed reports a failure rather than being repaired, and code that parses but is questionable is formatted without comment.
-
A project with its own formatter should use that:
Prettier and ESLint carry a project's agreed style. This is for a snippet from somewhere else, or a file with no such setup.
The same library behind a great many editors' reformat command
Formatting is handled by js-beautify, vendored locally rather than fetched from anywhere, which is the same library sitting behind the reformat command in a great many code editors. The [msm_tool slug="js-beautifier"] offers three modes — JavaScript, HTML and CSS — and they are genuinely separate parsers rather than one routine switching behaviour, which is why picking the wrong one produces indentation that is obviously wrong rather than subtly off.
It reformats, it does not rewrite
No variable is renamed, no statement is reordered, and no logic is touched at any point in the process. Code that was wrong before formatting is exactly as wrong afterwards — simply laid out more clearly, which makes the underlying problem easier to spot rather than fixing it automatically.
Choose the mode to match what was actually pasted
A template file full of markup wants the HTML mode even where its filename suggests otherwise, and JavaScript embedded directly inside a page gets formatted correctly by the HTML mode along with everything around it. The content in front of you, not the extension it happened to arrive with, is what should decide the mode.
It is not a linter
Nothing about the code is checked for correctness beyond whether it can be parsed at all. Code that fails to parse reports a failure rather than being repaired, and code that parses cleanly but is questionable in some other way is formatted exactly as given, without comment either way.
Why my code failed to format at all
A parse failure nearly always means a genuine syntax error somewhere in the source — an unclosed brace, bracket or string being the usual culprits. The formatter has no way to guess past a broken structure, so it reports the failure rather than attempting a repair that could easily make things worse.
Where a project's own formatter should win instead
Prettier and ESLint carry a project's specifically agreed style, and using this instead of either where one is already configured would fight against decisions the project has already made. This tool exists for a snippet arriving from somewhere else, or a file that has no formatting setup behind it at all.