Prettier is an opinionated code formatter that supports many languages and integrates with most editors. It removes all original styling and ensures that all outputted code conforms to a consistent style.
Code Formatting
Formats all .js files in the src directory and its subdirectories. When run, this command will process each JavaScript file and reformat it according to Prettier's rules.
prettier --write 'src/**/*.js'Configuration Overrides
Allows customization of Prettier's default formatting rules. For example, this JSON configuration disables semicolons at the end of statements and enforces single quotes.
{
'semi': false,
'singleQuote': true
}Ignoring Code
You can prevent a section of code from being formatted by Prettier by adding a special comment, `// prettier-ignore`, before it.
// prettier-ignore
let untouched = 'This code will not be formatted by Prettier.';Integration with Editors
Prettier can be integrated into many code editors to automatically format files on save or during editing, enhancing the developer's workflow.
N/ASupport for Multiple Languages
Prettier supports a wide range of languages and frameworks, including but not limited to JavaScript, TypeScript, CSS, HTML, and Markdown, making it a versatile tool for many developers.
N/AESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the ability to fix many issues automatically. While it can also format code, its primary focus is on code quality and adherence to coding standards, unlike Prettier which is solely focused on code formatting.
Stylelint is a modern linter that helps you avoid errors and enforce conventions in your stylesheets. It is to CSS what ESLint is to JavaScript, and while it can fix code style issues, it is more focused on maintaining code quality rather than just formatting.
Beautify, available as 'js-beautify' for npm, is a code beautifier that can format HTML, CSS, and JavaScript. It is less opinionated than Prettier and offers more configuration options, but it might not enforce as consistent a style as Prettier does.
Standard is a JavaScript style guide, linter, and formatter that enforces a strict coding standard. Unlike Prettier, Standard also includes rules that aim to prevent bugs and improve code clarity.
Prettier is an opinionated code formatter with support for:
It removes all original styling* and ensures that all outputted code conforms to a consistent style. (See this blog post)
Prettier takes your code and reprints it from scratch by taking the line length into account.
For example, take the following code:
foo(arg1, arg2, arg3, arg4);
It fits in a single line so it's going to stay as is. However, we've all run into this situation:
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
Suddenly our previous format for calling function breaks down because this is too long. Prettier is going to do the painstaking work of reprinting it like that for you:
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne()
);
Prettier enforces a consistent code style (i.e. code formatting that won't affect the AST) across your entire codebase because it disregards the original styling* by parsing it away and re-printing the parsed AST with its own rules that take the maximum line length into account, wrapping code when necessary.
*Well actually, some original styling is preserved when practical—see empty lines and multi-line objects.
If you want to learn more, these two conference talks are great introductions:
By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles. It is generally accepted that having a common style guide is valuable for a project and team but getting there is a very painful and unrewarding process. People get very emotional around particular ways of writing code and nobody likes spending time writing and receiving nits.
Prettier is usually introduced by people with experience in the current codebase and JavaScript but the people that disproportionally benefit from it are newcomers to the codebase. One may think that it's only useful for people with very limited programming experience, but we've seen it quicken the ramp up time from experienced engineers joining the company, as they likely used a different coding style before, and developers coming from a different programming language.
What usually happens once people are using Prettier is that they realize that they actually spend a lot of time and mental energy formatting their code. With Prettier editor integration, you can just press that magic key binding and poof, the code is formatted. This is an eye opening experience if anything else.
We've worked very hard to use the least controversial coding styles, went through many rounds of fixing all the edge cases and polished the getting started experience. When you're ready to push Prettier into your codebase, not only should it be painless for you to do it technically but the newly formatted codebase should not generate major controversy and be accepted painlessly by your co-workers.
Since coming up with a coding style and enforcing it is a big undertaking, it often slips through the cracks and you are left working on inconsistent codebases. Running Prettier in this case is a quick win, the codebase is now uniform and easier to read without spending hardly any time.
Purely technical aspects of the projects aren't the only thing people look into when choosing to adopt Prettier. Who built and uses it and how quickly it spreads through the community have a non trivial impact.
A few of the many projects using Prettier:
Linters have two categories of rules:
Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style...
Prettier makes this whole category of rules not needed anymore! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore :)
Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors...
Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!
Install:
yarn add prettier --dev
You can install it globally if you like:
yarn global add prettier
We're using yarn but you can use npm if you like:
npm install [--save-dev|--global] prettier
Run Prettier through the CLI with this script. Run it without any arguments to see the options.
To format a file in-place, use --write. You may want to consider
committing your code before doing that, just in case.
prettier [opts] [filename ...]
In practice, this may look something like:
prettier --single-quote --trailing-comma es5 --write "{app,__{tests,mocks}__}/**/*.js"
Don't forget the quotes around the globs! The quotes make sure that Prettier expands the globs rather than your shell, for cross-platform usage. The glob syntax from the glob module is used.
Prettier CLI will ignore files located in node_modules directory. To opt-out from this behavior use --with-node-modules flag.
If you're worried that Prettier will change the correctness of your code, add --debug-check to the command.
This will cause Prettier to print an error message if it detects that code correctness might have changed.
Note that --write cannot be used with --debug-check.
Another useful flag is --list-different (or -l) which prints the filenames of files that are different from Prettier formatting. If there are differences the script errors out, which is useful in a CI scenario.
prettier --single-quote --list-different "src/**/*.js"
If you are using ESLint, integrating Prettier to your workflow is straightforward:
Just add Prettier as an ESLint rule using eslint-plugin-prettier.
yarn add --dev prettier eslint-plugin-prettier
// .eslintrc
{
"plugins": [
"prettier"
],
"rules": {
"prettier/prettier": "error"
}
}
We also recommend that you use eslint-config-prettier to disable all the existing formatting rules. It's a one liner that can be added on-top of any existing ESLint configuration.
$ yarn add --dev eslint-config-prettier
.eslintrc.json:
{
"extends": [
"prettier"
]
}
You can use Prettier with a pre-commit tool. This can re-format your files that are marked as "staged" via git add before you commit.
Install it along with husky:
yarn add lint-staged husky --dev
and add this config to your package.json:
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"*.js": [
"prettier --write",
"git add"
]
}
}
See https://github.com/okonet/lint-staged#configuration for more details about how you can configure lint-staged.
Copy the following config in your pre-commit config yaml file:
- repo: https://github.com/awebdeveloper/pre-commit-prettier
sha: '' # Use the sha or tag you want to point at
hooks:
- id: prettier
additional_dependencies: ['prettier@1.4.2']
Find more info from here.
Alternately you can save this script as .git/hooks/pre-commit and give it execute permission:
#!/bin/sh
jsfiles=$(git diff --cached --name-only --diff-filter=ACM | grep '\.jsx\?$' | tr '\n' ' ')
[ -z "$jsfiles" ] && exit 0
diffs=$(node_modules/.bin/prettier -l $jsfiles)
[ -z "$diffs" ] && exit 0
echo "here"
echo >&2 "Javascript files must be formatted with Prettier. Please run:"
echo >&2 "node_modules/.bin/prettier --write "$diffs""
exit 1
The API has three functions: format, check, and formatWithCursor.
const prettier = require("prettier");
prettier.format(source [, options])format is used to format text using Prettier. Options may be provided to override the defaults.
prettier.format("foo ( );", { semi: false });
// -> "foo()"
prettier.check(source [, options])check checks to see if the file has been formatted with Prettier given those options and returns a Boolean.
This is similar to the --list-different parameter in the CLI and is useful for running Prettier in CI scenarios.
prettier.formatWithCursor(source [, options])formatWithCursor both formats the code, and translates a cursor position from unformatted code to formatted code.
This is useful for editor integrations, to prevent the cursor from moving when code is formatted.
The cursorOffset option should be provided, to specify where the cursor is. This option cannot be used with rangeStart and rangeEnd.
prettier.formatWithCursor(" 1", { cursorOffset: 2 });
// -> { formatted: '1;\n', cursorOffset: 1 }
If you need to make modifications to the AST (such as codemods), or you want to provide an alternate parser, you can do so by setting the parser option to a function. The function signature of the parser function is:
(text: string, parsers: object, options: object) => AST;
Prettier's built-in parsers are exposed as properties on the parsers argument.
prettier.format("lodash ( )", {
parser(text, { babylon }) {
const ast = babylon(text);
ast.program.body[0].expression.callee.name = "_";
return ast;
}
});
// -> "_();\n"
The --parser CLI option may be a path to a node.js module exporting a parse function.
A JavaScript comment of // prettier-ignore will exclude the next node in the abstract syntax tree from formatting.
For example:
matrix(
1, 0, 0,
0, 1, 0,
0, 0, 1
)
// prettier-ignore
matrix(
1, 0, 0,
0, 1, 0,
0, 0, 1
)
will be transformed to:
matrix(1, 0, 0, 0, 1, 0, 0, 0, 1);
// prettier-ignore
matrix(
1, 0, 0,
0, 1, 0,
0, 0, 1
)
Prettier ships with a handful of customizable format options, usable in both the CLI and API.
Specify the length of line that the printer will wrap on.
We strongly recommend against using more than 80 columns.
Prettier works by cramming as much content as possible until it reaches the limit, which happens to work well for 80 columns but makes lines that are very crowded. When a bigger column count is used in styleguides, it usually means that code is allowed to go beyond 80 columns, but not to make every single line go there, like Prettier would do.
| Default | CLI Override | API Override |
|---|---|---|
80 | --print-width <int> | printWidth: <int> |
Specify the number of spaces per indentation-level.
| Default | CLI Override | API Override |
|---|---|---|
2 | --tab-width <int> | tabWidth: <int> |
Indent lines with tabs instead of spaces
| Default | CLI Override | API Override |
|---|---|---|
false | --use-tabs | useTabs: <bool> |
Print semicolons at the ends of statements.
Valid options:
true - Add a semicolon at the end of every statement.false - Only add semicolons at the beginning of lines that may introduce ASI failures.| Default | CLI Override | API Override |
|---|---|---|
true | --no-semi | semi: <bool> |
Use single quotes instead of double quotes.
Notes:
"I'm double quoted" results in "I'm double quoted" and "This \"example\" is single quoted" results in 'This "example" is single quoted'.| Default | CLI Override | API Override |
|---|---|---|
false | --single-quote | singleQuote: <bool> |
Print trailing commas wherever possible.
Valid options:
"none" - No trailing commas."es5" - Trailing commas where valid in ES5 (objects, arrays, etc.)"all" - Trailing commas wherever possible (function arguments). This requires node 8 or a transform.| Default | CLI Override | API Override |
|---|---|---|
"none" | --trailing-comma <none|es5|all> | trailingComma: "<none|es5|all>" |
Print spaces between brackets in object literals.
Valid options:
true - Example: { foo: bar }.false - Example: {foo: bar}.| Default | CLI Override | API Override |
|---|---|---|
true | --no-bracket-spacing | bracketSpacing: <bool> |
Put the > of a multi-line JSX element at the end of the last line instead of being alone on the next line.
| Default | CLI Override | API Override |
|---|---|---|
false | --jsx-bracket-same-line | jsxBracketSameLine: <bool> |
Format only a segment of a file.
These two options can be used to format code starting and ending at a given character offset (inclusive and exclusive, respectively). The range will extend:
These options cannot be used with cursorOffset.
| Default | CLI Override | API Override |
|---|---|---|
0 | --range-start <int> | rangeStart: <int> |
Infinity | --range-end <int> | rangeEnd: <int> |
Specify which parser to use.
Both the babylon and flow parsers support the same set of JavaScript features (including Flow). Prettier automatically infers the parser from the input file path, so you shouldn't have to change this setting.
Built-in parsers:
Custom parsers are also supported. Since v1.5.0
| Default | CLI Override | API Override |
|---|---|---|
babylon | --parser <string>--parser ./my-parser | parser: "<string>"parser: require("./my-parser") |
Specify the input filepath. This will be used to do parser inference.
For example, the following will use postcss parser:
cat foo | prettier --stdin-filepath foo.css
| Default | CLI Override | API Override |
|---|---|---|
| None | --stdin-filepath <string> | filepath: "<string>" |
Atom users can simply install the prettier-atom package and use
Ctrl+Alt+F to format a file (or format on save if enabled).
Emacs users should see this repository for on-demand formatting.
Vim users can simply install either sbdchd/neoformat or mitermayer/vim-prettier, for more details see this directory
Can be installed using the extension sidebar. Search for Prettier - JavaScript formatter.
Can also be installed using ext install prettier-vscode.
Check its repository for configuration and shortcuts
Install the JavaScript Prettier extension.
Sublime Text support is available through Package Control and the JsPrettier plug-in.
See the WebStorm guide.
Prettier attempts to support all JavaScript language features,
including non-standardized ones. By default it uses the
Babylon parser with all language
features enabled, but you can also use the
Flow parser with the
parser API or --parser CLI option.
All of JSX and Flow syntax is supported. In fact, the test suite in
tests is the entire Flow test suite and they all pass.
Prettier also supports TypeScript, CSS, LESS, SCSS, JSON, and GraphQL.
The minimum version of TypeScript supported is 2.1.3 as it introduces the ability to have leading | for type definitions which prettier outputs.
eslint-plugin-prettier plugs Prettier into your ESLint workfloweslint-config-prettier turns off all ESLint rules that are unnecessary or might conflict with Prettierprettier-eslint
passes prettier output to eslint --fixprettier-standard
uses prettier and prettier-eslint to format code with standard rulesprettier-standard-formatter
passes prettier output to standard --fixprettier-miscellaneous
prettier with a few minor extra optionsneutrino-preset-prettier allows you to use Prettier as a Neutrino presetprettier_d runs Prettier as a server to avoid Node.js startup delayPrettier Bookmarklet provides a bookmarklet and exposes a REST API for Prettier that allows to format CodeMirror editor in your browserprettier-github formats code in GitHub commentsThis printer is a fork of recast's printer with its algorithm replaced by the one described by Wadler in "A prettier printer". There still may be leftover code from recast that needs to be cleaned up.
The basic idea is that the printer takes an AST and returns an intermediate representation of the output, and the printer uses that to generate a string. The advantage is that the printer can "measure" the IR and see if the output is going to fit on a line, and break if not.
This means that most of the logic of printing an AST involves
generating an abstract representation of the output involving certain
commands. For example, concat(["(", line, arg, line ")"]) would
represent a concatenation of opening parens, an argument, and closing
parens. But if that doesn't fit on one line, the printer can break
where line is specified.
More (rough) details can be found in commands.md.
Show the world you're using Prettier →
[](https://github.com/prettier/prettier)
See CONTRIBUTING.md.
1.5.2
FAQs
Prettier is an opinionated code formatter
The npm package prettier receives a total of 24,089,349 weekly downloads. As such, prettier popularity was classified as popular.
We found that prettier demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
RubyGems.org has added a new "maintainer" role that allows for publishing new versions of gems. This new permission type is aimed at improving security for gem owners and the service overall.
Security News
Node.js will be enforcing stricter semver-major PR policies a month before major releases to enhance stability and ensure reliable release candidates.
Security News
Research
Socket's threat research team has detected five malicious npm packages targeting Roblox developers, deploying malware to steal credentials and personal data.