Prettier 配置生成器
指导
Prettier 配置生成器
Build a correct Prettier configuration without hunting through the docs. Pick every formatting option from a checklist, add per-language overrides for Markdown, HTML, YAML and JSON, and export the result as .prettierrc.json, .prettierrc.yaml, an ES module, a CommonJS module, or a ready-to-paste "prettier" key for package.json. A matching .prettierignore template is generated alongside it so your repository is ready to format on the first commit.
如何使用
- 选择一个 输出格式 — JSON for the simplest shareable file, YAML for human-friendly editing, a JS module when you need conditional logic, or the package.json key when you want one less file in the repo.
- 设置 core options: line width, tab width, semicolons, quote style, trailing commas, bracket spacing, arrow-function parens, and end-of-line style.
- Tune the JSX block if your codebase uses React, and the Markdown & HTML block for prose-wrapping and whitespace handling.
- Enable any per-language overrides to apply different rules to specific file types — for example, a wider
printWidthfor JSON, or single-attribute-per-line for HTML. - 点击 复制 或 下载 on the generated config. Drop it at the root of your project and run
npx prettier --write ..
特征
- Every official Prettier option — printWidth, tabWidth, useTabs, semi, singleQuote, quoteProps, jsxSingleQuote, trailingComma, bracketSpacing, bracketSameLine, arrowParens, endOfLine, proseWrap, htmlWhitespaceSensitivity, singleAttributePerLine.
- Five output formats — JSON, YAML, ESM (.mjs), CommonJS (.cjs), and a package.json fragment.
- Per-language override blocks for Markdown, HTML, YAML, and JSON with sensible defaults you can copy as-is or tweak.
- Auto-generated
.prettierignoretemplate covering build output, dependencies, lock files, minified assets, and common framework cache folders. - JSDoc
@typeannotation on JS module outputs so editors light up with autocomplete and type checking. - 实时预览 — every change updates the output immediately, so you can A/B compare option combinations in seconds.
常问问题
-
Why does Prettier deliberately have so few options?
Prettier's design goal is to end style debates by being opinionated. Each option that exists was added reluctantly, because consensus on the 'right' default was impossible. The team explicitly resists new options to keep configs portable and reviews predictable across projects. That is why something like 'spaces around keywords' is not configurable — Prettier treats formatting choices as commodity decisions, not personal expression.
-
What is the difference between trailingComma 'es5' and 'all'?
'es5' adds trailing commas where ECMAScript 5 allowed them — arrays and objects — but not in function parameters or calls. 'all' also adds them to function parameter lists and call sites, which is valid in ES2017+ and gives cleaner git diffs when arguments are added or removed. 'all' is the current Prettier default and the recommended choice for any project that targets modern JS or transpiles.
-
How does Prettier interact with ESLint?
Prettier handles formatting; ESLint handles correctness. They overlap on stylistic rules like quotes and semicolons, which causes conflicts where ESLint reports issues that Prettier just rewrites. The fix is eslint-config-prettier — a sharable config that disables every ESLint rule Prettier already controls. Run Prettier first to format, then ESLint to catch bugs. Plugins like eslint-plugin-prettier that run Prettier as a lint rule are no longer recommended because they slow down ESLint and obscure error sources.
-
What does proseWrap do in Markdown files?
'preserve' keeps your existing line breaks untouched. 'always' hard-wraps prose at printWidth so the source is readable in any editor, which works well for documentation repos. 'never' joins wrapped paragraphs into single lines, which is the right choice for files that will be edited by tools or rendered in environments where line breaks would show as separate paragraphs. The default is 'preserve' because Markdown line endings can change semantics in some flavors.
-
When should I use a JS config over JSON?
Use JSON when the config is static and shared across the team — it is the simplest, most portable form. Use a JS config when you need to import shared rules from a package, swap options based on an environment variable, derive overrides from glob lists in code, or use TypeScript types via the JSDoc @type import. JS configs are slower to load because Prettier has to execute them, but the cost is invisible at editor save speeds.
