1"use strict";(self.webpackChunk=self.webpackChunk||[]).push([["9339"],{6955(e,n,t){t.r(n),t.d(n,{metadata:()=>i,default:()=>h,frontMatter:()=>r,contentTitle:()=>a,toc:()=>c,assets:()=>l});var i=JSON.parse('{"id":"rationale","title":"Rationale","description":"Prettier is an opinionated code formatter. This document explains some of its choices.","source":"@site/versioned_docs/version-stable/rationale.md","sourceDirName":".","slug":"/rationale","permalink":"/docs/rationale","draft":false,"unlisted":false,"editUrl":"https://github.com/prettier/prettier/edit/main/docs/rationale.md","tags":[],"version":"stable","frontMatter":{"id":"rationale","title":"Rationale"},"sidebar":"docs","previous":{"title":"Option Philosophy","permalink":"/docs/option-philosophy"},"next":{"title":"Install","permalink":"/docs/install"}}'),s=t(4848),o=t(8453);let r={id:"rationale",title:"Rationale"},a,l={},c=[{value:"What Prettier is concerned about",id:"what-prettier-is-concerned-about",level:2},{value:"Correctness",id:"correctness",level:3},{value:"Strings",id:"strings",level:3},{value:"Empty lines",id:"empty-lines",level:3},{value:"Multi-line objects",id:"multi-line-objects",level:3},{value:"Decorators",id:"decorators",level:3},{value:"Template literals",id:"template-literals",level:3},{value:"Semicolons",id:"semicolons",level:3},{value:"Print width",id:"print-width",level:3},{value:"Imports",id:"imports",level:4},{value:"Testing functions",id:"testing-functions",level:4},{value:"JSX",id:"jsx",level:3},{value:"Comments",id:"comments",level:3},{value:"Disclaimer about non-standard syntax",id:"disclaimer-about-non-standard-syntax",level:2},{value:"Disclaimer about machine-generated files",id:"disclaimer-about-machine-generated-files",level:2},{value:"What Prettier is <em>not</em> concerned about",id:"what-prettier-is-not-concerned-about",level:2}];function d(e){let n={a:"a",admonition:"admonition",code:"code",em:"em",h2:"h2",h3:"h3",h4:"h4",li:"li",p:"p",pre:"pre",strong:"strong",ul:"ul",...(0,o.R)(),...e.components};return(0,s.jsxs)(s.Fragment,{children:[(0,s.jsx)(n.p,{children:"Prettier is an opinionated code formatter. This document explains some of its choices."}),"\n",(0,s.jsx)(n.h2,{id:"what-prettier-is-concerned-about",children:"What Prettier is concerned about"}),"\n",(0,s.jsx)(n.h3,{id:"correctness",children:"Correctness"}),"\n",(0,s.jsx)(n.p,{children:"The first requirement of Prettier is to output valid code that has the exact same behavior as before formatting. Please report any code where Prettier fails to follow these correctness rules \u2014 that\u2019s a bug which needs to be fixed!"}),"\n",(0,s.jsx)(n.h3,{id:"strings",children:"Strings"}),"\n",(0,s.jsxs)(n.p,{children:["Double or single quotes? Prettier chooses the one which results in the fewest number of escapes. ",(0,s.jsx)(n.code,{children:"\"It's gettin' better!\""}),", not ",(0,s.jsx)(n.code,{children:"'It\\'s gettin\\' better!'"}),". In case of a tie or the string not containing any quotes, Prettier defaults to double quotes (but that can be changed via the ",(0,s.jsx)(n.a,{href:"/docs/options#quotes",children:"singleQuote"})," option)."]}),"\n",(0,s.jsxs)(n.p,{children:["JSX has its own option for quotes: ",(0,s.jsx)(n.a,{href:"/docs/options#jsx-quotes",children:"jsxSingleQuote"}),'.\nJSX takes its roots from HTML, where the dominant use of quotes for attributes is double quotes. Browser developer tools also follow this convention by always displaying HTML with double quotes, even if the source code uses single quotes. A separate option allows using single quotes for JS and double quotes for "HTML" (JSX).']}),"\n",(0,s.jsxs)(n.p,{children:["Prettier maintains the way your string is escaped. For example, ",(0,s.jsx)(n.code,{children:'"\u{1F642}"'})," won\u2019t be formatted into ",(0,s.jsx)(n.code,{children:'"\\uD83D\\uDE42"'})," and vice versa."]}),"\n",(0,s.jsx)(n.h3,{id:"empty-lines",children:"Empty lines"}),"\n",(0,s.jsx)(n.p,{children:"It turns out that empty lines are very hard to automatically generate. The approach that Prettier takes is to preserve empty lines the way they were in the original source code. There are two additional rules:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Prettier collapses multiple blank lines into a single blank line."}),"\n",(0,s.jsx)(n.li,{children:"Empty lines at the start and end of blocks (and whole files) are removed. (Files always end with a single newline, though.)"}),"\n"]}),"\n",(0,s.jsx)(n.h3,{id:"multi-line-objects",children:"Multi-line objects"}),"\n",(0,s.jsxs)(n.p,{children:["By default, Prettier\u2019s printing algorithm prints expressions on a single line if they fit. Objects are used for a lot of different things in JavaScript, though, and sometimes it really helps readability if they stay multiline. See ",(0,s.jsx)(n.a,{href:"https://github.com/prettier/prettier/issues/74#issue-199965534",children:"object lists"}),", ",(0,s.jsx)(n.a,{href:"https://github.com/prettier/prettier/issues/88#issuecomment-275448346",children:"nested configs"}),", ",(0,s.jsx)(n.a,{href:"https://github.com/prettier/prettier/issues/74#issuecomment-275262094",children:"stylesheets"})," and ",(0,s.jsx)(n.a,{href:"https://github.com/prettier/prettier/pull/495#issuecomment-275745434",children:"keyed methods"}),", for example. We haven\u2019t been able to find a good rule for all those cases, so by default Prettier keeps objects multi-line if there\u2019s a newline between the ",(0,s.jsx)(n.code,{children:"{"})," and the first key in the original source code. Consequently, long single-line objects are automatically expanded, but short multi-line objects are never collapsed."]}),"\n",(0,s.jsxs)(n.p,{children:["You can disable this conditional behavior with the ",(0,s.jsx)(n.a,{href:"/docs/options#object-wrap",children:(0,s.jsx)(n.code,{children:"objectWrap"})})," option."]}),"\n",(0,s.jsxs)(n.p,{children:[(0,s.jsx)(n.strong,{children:"Tip:"})," If you have a multi-line object that you\u2019d like to join up into a single line:"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'const user = {\
1n name: "John Doe",\n age: 30\n};\n'})}),"\n",(0,s.jsxs)(n.p,{children:["\u2026all you need to do is remove the newline after ",(0,s.jsx)(n.code,{children:"{"}),":"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'const user = { name: "John Doe",\n age: 30\n};\n'})}),"\n",(0,s.jsx)(n.p,{children:"\u2026and then run Prettier:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'const user = { name: "John Doe", age: 30 };\n'})}),"\n",(0,s.jsxs)(n.p,{children:["And if you\u2019d like to go multi-line again, add in a newline after ",(0,s.jsx)(n.code,{children:"{"}),":"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'const user = {\n name: "John Doe", age: 30 };\n'})}),"\n",(0,s.jsx)(n.p,{children:"\u2026and run Prettier:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'const user = {\n name: "John Doe",\n age: 30,\n};\n'})}),"\n",(0,s.jsxs)(n.admonition,{title:"A note on formatting reversibility",type:"note",children:[(0,s.jsxs)(n.p,{children:["The semi-manual formatting for object literals is in fact a workaround, not a feature. It was implemented only because at the time a good heuristic wasn\u2019t found and an urgent fix was needed. However, as a general strategy, Prettier avoids ",(0,s.jsx)(n.em,{children:"non-reversible"})," formatting like that, so the team is still looking for heuristics that would allow either to remove this behavior completely or at least to reduce the number of situations where it\u2019s applied."]}),(0,s.jsxs)(n.p,{children:["What does ",(0,s.jsx)(n.strong,{children:"reversible"})," mean? Once an object literal becomes multiline, Prettier won\u2019t collapse it back. If in Prettier-formatted code, we add a property to an object literal, run Prettier, then change our mind, remove the added property, and then run Prettier again, we might end up with a formatting not identical to the initial one. This useless change might even get included in a commit, which is exactly the kind of situation Prettier was created to prevent."]})]}),"\n",(0,s.jsx)(n.h3,{id:"decorators",children:"Decorators"}),"\n",(0,s.jsxs)(n.p,{children:["Just like with objects, decorators are used for a lot of different things. Sometimes it makes sense to write decorators ",(0,s.jsx)(n.em,{children:"above"})," the line they're decorating, sometimes it\u2019s nicer if they're on the ",(0,s.jsx)(n.em,{children:"same"})," line. We haven\u2019t been able to find a good rule for this, so Prettier keeps your decorator positioned like you wrote them (if they fit on the line). This isn\u2019t ideal, but a pragmatic solution to a difficult problem."]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-ts",children:'@Component({\n selector: "hero-button",\n template: `<button>{{ label }}</button>`,\n})\nclass HeroButtonComponent {\n // These decorators were written inline and fit on the line so they stay\n // inline.\n @Output() change = new EventEmitter();\n @Input() label: string;\n\n // These were written multiline, so they stay multiline.\n @readonly\n @nonenumerable\n NODE_TYPE: 2;\n}\n'})}),"\n",(0,s.jsx)(n.p,{children:"There\u2019s one exception: classes. We don\u2019t think it ever makes sense to inline the decorators for them, so they are always moved to their own line."}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-ts",children:"// Before running Prettier:\n@observer class OrderLine {\n @observable price: number = 0;\n}\n"})}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-ts",children:"// After running Prettier:\n@observer\nclass OrderLine {\n @observable price: number = 0;\n}\n"})}),"\n",(0,s.jsx)(n.p,{children:"Note: Prettier 1.14.x and older tried to automatically move your decorators, so if you've run an older Prettier version on your code you might need to manually join up some decorators here and there to avoid inconsistencies:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-ts",children:"@observer\nclass OrderLine {\n @observable price: number = 0;\n @observable\n amount: number = 0;\n}\n"})}
1),"\n",(0,s.jsx)(n.h3,{id:"template-literals",children:"Template literals"}),"\n",(0,s.jsx)(n.p,{children:"Template literals can contain interpolations. Deciding whether it's appropriate to insert a linebreak within an interpolation unfortunately depends on the semantic content of the template - for example, introducing a linebreak in the middle of a natural-language sentence is usually undesirable. Since Prettier doesn't have enough information to make this decision itself, it uses a heuristic similar to that used for objects: it will only split an interpolation expression across multiple lines if there was already a linebreak within that interpolation."}),"\n",(0,s.jsx)(n.p,{children:"This means that a literal like the following will not be broken onto multiple lines, even if it exceeds the print width:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"`this is a long message which contains an interpolation: ${format(data)} <- like this`;\n"})}),"\n",(0,s.jsxs)(n.p,{children:["If you want Prettier to split up an interpolation, you'll need to ensure there's a linebreak somewhere within the ",(0,s.jsx)(n.code,{children:"${...}"}),". Otherwise it will keep everything on a single line, no matter how long it is."]}),"\n",(0,s.jsx)(n.p,{children:"The team would prefer not to depend on the original formatting in this way, but it's the best heuristic we have at the moment."}),"\n",(0,s.jsx)(n.h3,{id:"semicolons",children:"Semicolons"}),"\n",(0,s.jsxs)(n.p,{children:["This is about using the ",(0,s.jsx)(n.a,{href:"/docs/options#semicolons",children:"noSemi"})," option."]}),"\n",(0,s.jsx)(n.p,{children:"Consider this piece of code:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"if (shouldAddLines) {\n [-1, 1].forEach(delta => addLine(delta * 20))\n}\n"})}),"\n",(0,s.jsx)(n.p,{children:"While the above code works just fine without semicolons, Prettier actually turns it into:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"if (shouldAddLines) {\n ;[-1, 1].forEach(delta => addLine(delta * 20))\n}\n"})}),"\n",(0,s.jsxs)(n.p,{children:["This is to help you avoid mistakes. Imagine Prettier ",(0,s.jsx)(n.em,{children:"not"})," inserting that semicolon and adding this line:"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-diff",children:" if (shouldAddLines) {\n+ console.log('Do we even get here??')\n [-1, 1].forEach(delta => addLine(delta * 20))\n }\n"})}),"\n",(0,s.jsx)(n.p,{children:"Oops! The above actually means:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"if (shouldAddLines) {\n console.log('Do we even get here??')[-1, 1].forEach(delta => addLine(delta * 20))\n}\n"})}),"\n",(0,s.jsxs)(n.p,{children:["With a semicolon in front of that ",(0,s.jsx)(n.code,{children:"["})," such issues never happen. It makes the line independent of other lines so you can move and add lines without having to think about ASI rules."]}),"\n",(0,s.jsxs)(n.p,{children:["This practice is also common in ",(0,s.jsx)(n.a,{href:"https://standardjs.com/rules.html#semicolons",children:"standard"})," which uses a semicolon-free style."]}),"\n",(0,s.jsxs)(n.p,{children:["Note that if your program currently has a semicolon-related bug in it, Prettier ",(0,s.jsx)(n.em,{children:"will not"})," auto-fix the bug for you. Remember, Prettier only reformats code, it does not change the behavior of the code. Take this buggy piece of code as an example, where the developer forgot to place a semicolon before the ",(0,s.jsx)(n.code,{children:"("}),":"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"console.log('Running a background task')\n(async () => {\n await doBackgroundWork()\n})()\n"})}),"\n",(0,s.jsx)(n.p,{children:"If you feed this into Prettier, it will not alter the behavior of this code; instead, it will reformat it in a way that shows how this code will actually behave when run."}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'console.log("Running a background task")(async () =>
1 {\n await doBackgroundWork();\n})();\n'})}),"\n",(0,s.jsx)(n.h3,{id:"print-width",children:"Print width"}),"\n",(0,s.jsxs)(n.p,{children:["The ",(0,s.jsx)(n.a,{href:"/docs/options#print-width",children:"printWidth"})," option is more of a guideline to Prettier than a hard rule. It is not the upper allowed line length limit. It is a way to say to Prettier roughly how long you\u2019d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified print width."]}),"\n",(0,s.jsxs)(n.p,{children:["There are some edge cases, such as really long string literals, regexps, comments and variable names, which cannot be broken across lines (without using code transforms which ",(0,s.jsx)(n.a,{href:"#what-prettier-is-not-concerned-about",children:"Prettier doesn\u2019t do"}),"). Or if you nest your code 50 levels deep your lines are of course going to be mostly indentation :)"]}),"\n",(0,s.jsx)(n.p,{children:"Apart from that, there are a few cases where Prettier intentionally exceeds the print width."}),"\n",(0,s.jsx)(n.h4,{id:"imports",children:"Imports"}),"\n",(0,s.jsxs)(n.p,{children:["Prettier can break long ",(0,s.jsx)(n.code,{children:"import"})," statements across several lines:"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'import {\n CollectionDashboard,\n DashboardPlaceholder,\n} from "../components/collections/collection-dashboard/main";\n'})}),"\n",(0,s.jsx)(n.p,{children:"The following example doesn\u2019t fit within the print width, but Prettier prints it in a single line anyway:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'import { CollectionDashboard } from "../components/collections/collection-dashboard/main";\n'})}),"\n",(0,s.jsxs)(n.p,{children:["This might be unexpected by some, but we do it this way since it was a common request to keep ",(0,s.jsx)(n.code,{children:"import"}),"s with single elements in a single line. The same applies for ",(0,s.jsx)(n.code,{children:"require"})," calls."]}),"\n",(0,s.jsx)(n.h4,{id:"testing-functions",children:"Testing functions"}),"\n",(0,s.jsx)(n.p,{children:"Another common request was to keep lengthy test descriptions in one line, even if it gets too long. In such cases, wrapping the arguments to new lines doesn\u2019t help much."}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:'describe("NodeRegistry", () => {\n it("makes no request if there are no nodes to prefetch, even if the cache is stale", async () => {\n // The above line exceeds the print width but stayed on one line anyway.\n });\n});\n'})}),"\n",(0,s.jsxs)(n.p,{children:["Prettier has special cases for common testing framework functions such as ",(0,s.jsx)(n.code,{children:"describe"}),", ",(0,s.jsx)(n.code,{children:"it"})," and ",(0,s.jsx)(n.code,{children:"test"}),"."]}),"\n",(0,s.jsx)(n.h3,{id:"jsx",children:"JSX"}),"\n",(0,s.jsx)(n.p,{children:"Prettier prints things a little differently compared to other JS when JSX is involved:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-jsx",children:'function greet(user) {\n return user\n ? `Welcome back, ${user.name}!`\n : "Greetings, traveler! Sign up today!";\n}\n\nfunction Greet({ user }) {\n return (\n <div>\n {user ? (\n <p>Welcome back, {user.name}!</p>\n ) : (\n <p>Greetings, traveler! Sign up today!</p>\n )}\n </div>\n );\n}\n'})}),"\n",(0,s.jsx)(n.p,{children:"There are two reasons."}),"\n",(0,s.jsxs)(n.p,{children:["First off, lots of people already wrapped their JSX in parentheses, especially in ",(0,s.jsx)(n.code,{children:"return"})," statements. Prettier follows this common style."]}),"\n",(0,s.jsxs)(n.p,{children:["Secondly, ",(0,s.jsx)(n.a,{href:"https://github.com/prettier/prettier/issues/2208",children:"the alternate formatting makes it easier to edit the JSX"}),". It is easy to leave a semicolon behind. As opposed to normal JS, a leftover semicolon in JSX can end up as plain text showing on your page."]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-jsx",children:"<div>\n <p>Greetings, traveler! Sign up today!</p>; {/* <-- Oops! */}\n</div>\n"})}),"\n",(0,s.jsx)(n.h3,{id:"comments",children:"Comments"}),"\n",(0,s.jsxs)(n.p,{children:["When it comes to the ",(0,s.jsx)(n.em,{children:"content"})," of comments, Prettier can\u2019t do much really. Comments can contain everything from prose to commented out code and ASCII diagrams. Since they can contain anything, Prettier can\u2019t know how to format or wrap them. So they are left as-is. The only exception to this are JSDoc-style comments (block comments where every line starts with a ",(0,s.jsx)(n.code,{children:"*"}),"), which Prettier can fix the indentation of."]}),"\n",(0,s.jsxs)(n.p,{children:["Then there\u2019s the question of ",(0,s.jsx)(n.em,{children:"where"})," to put the comments. Turns out this is a really difficult problem. Prettier tries its best to keep your comments roughly where they were, but it\u2019s no easy task because comments can be placed almost anywhere."]}),"\n",(0,s.jsxs)(n.p,{children:["Generally, you get the best results when placing comments ",(0,s.jsx)(n.strong,{children:"on their own lines,"})," instead of at the end of lines. Prefer ",(0,s.jsx)(n.code,{children:"// eslint-disable-next-line"})," over ",(0,s.jsx)(n.code,{children:"// eslint-disable-line"}),"."]}),"\n",(0,s.jsxs)(n.p,{children:["Note that \u201Cmagic comments\u201D such as ",(0,s.jsx)(n.code,{children:"eslint-disable-next-line"})," and ",(0,s.jsx)(n.code,{children:"$FlowFixMe"})," might sometimes need to be manually moved due to Prettier breaking an expression into multiple lines."]}),"\n",(0,s.jsx)(n.p,{children:"Imagine this piece of code:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"// eslint-disable-next-line no-eval\nconst result = safeToEval ? eval(input) : fallback(input);\n"})}
1),"\n",(0,s.jsx)(n.p,{children:"Then you need to add another condition:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"// eslint-disable-next-line no-eval\nconst result = safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);\n"})}),"\n",(0,s.jsx)(n.p,{children:"Prettier will turn the above into:"}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"// eslint-disable-next-line no-eval\nconst result =\n safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);\n"})}),"\n",(0,s.jsxs)(n.p,{children:["Which means that the ",(0,s.jsx)(n.code,{children:"eslint-disable-next-line"})," comment is no longer effective. In this case you need to move the comment:"]}),"\n",(0,s.jsx)(n.pre,{children:(0,s.jsx)(n.code,{className:"language-js",children:"const result =\n // eslint-disable-next-line no-eval\n safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);\n"})}),"\n",(0,s.jsxs)(n.p,{children:["If possible, prefer comments that operate on line ranges (e.g. ",(0,s.jsx)(n.code,{children:"eslint-disable"})," and ",(0,s.jsx)(n.code,{children:"eslint-enable"}),") or on the statement level (e.g. ",(0,s.jsx)(n.code,{children:"/* istanbul ignore next */"}),"), they are even safer. It\u2019s possible to disallow using ",(0,s.jsx)(n.code,{children:"eslint-disable-line"})," and ",(0,s.jsx)(n.code,{children:"eslint-disable-next-line"})," comments using ",(0,s.jsx)(n.a,{href:"https://github.com/mysticatea/eslint-plugin-eslint-comments",children:(0,s.jsx)(n.code,{children:"eslint-plugin-eslint-comments"})}),"."]}),"\n",(0,s.jsx)(n.h2,{id:"disclaimer-about-non-standard-syntax",children:"Disclaimer about non-standard syntax"}),"\n",(0,s.jsx)(n.p,{children:"Prettier is often able to recognize and format non-standard syntax such as ECMAScript early-stage proposals and Markdown syntax extensions not defined by any specification. The support for such syntax is considered best-effort and experimental. Incompatibilities may be introduced in any release and should not be viewed as breaking changes."}),"\n",(0,s.jsx)(n.h2,{id:"disclaimer-about-machine-generated-files",children:"Disclaimer about machine-generated files"}),"\n",(0,s.jsxs)(n.p,{children:["Some files, like ",(0,s.jsx)(n.code,{children:"package.json"})," or ",(0,s.jsx)(n.code,{children:"composer.lock"}),", are machine-generated and regularly updated by the package manager. If Prettier were to use the same JSON formatting rules as with other files, it would regularly conflict with these other tools. To avoid this inconvenience, Prettier will use a formatter based on ",(0,s.jsx)(n.code,{children:"JSON.stringify"})," on such files instead. You may notice these differences, such as the removal of vertical whitespace, but this is an intended behavior."]}),"\n",(0,s.jsxs)(n.h2,{id:"what-prettier-is-not-concerned-about",children:["What Prettier is ",(0,s.jsx)(n.em,{children:"not"})," concerned about"]}),"\n",(0,s.jsxs)(n.p,{children:["Prettier only ",(0,s.jsx)(n.em,{children:"prints"})," code. It does not transform it. This is to limit the scope of Prettier. Let\u2019s focus on the printing and do it really well!"]}),"\n",(0,s.jsx)(n.p,{children:"Here are a few examples of things that are out of scope for Prettier:"}),"\n",(0,s.jsxs)(n.ul,{children:["\n",(0,s.jsx)(n.li,{children:"Turning single- or double-quoted strings into template literals or vice versa."}),"\n",(0,s.jsxs)(n.li,{children:["Using ",(0,s.jsx)(n.code,{children:"+"})," to break long string literals into parts that fit the print width."]}),"\n",(0,s.jsxs)(n.li,{children:["Adding/removing ",(0,s.jsx)(n.code,{children:"{}"})," and ",(0,s.jsx)(n.code,{children:"return"})," where they are optional."]}),"\n",(0,s.jsxs)(n.li,{children:["Turning ",(0,s.jsx)(n.code,{children:"?:"})," into ",(0,s.jsx)(n.code,{children:"if"}),"-",(0,s.jsx)(n.code,{children:"else"})," statements."]}),"\n",(0,s.jsxs)(n.li,{children:["Sorting/moving imports, object keys, class members, JSX keys, CSS properties or anything else. Apart from being a ",(0,s.jsx)(n.em,{children:"transform"})," rather than just printing (as mentioned above), sorting is potentially unsafe because of side effects (for imports, as an example) and makes it difficult to verify the most important ",(0,s.jsx)(n.a,{href:"#correctness",children:"correctness"})," goal."]}),"\n"]})]})}function h(e={}){let{wrapper:n}={...(0,o.R)(),...e.components};return n?(0,s.jsx)(n,{...e,children:(0,s.jsx)(d,{...e})}):d(e)}},8453(e,n,t){t.d(n,{R:()=>r,x:()=>a});var i=t(6540);let s={},o=i.createContext(s);function r(e){let n=i.useContext(o);return i.useMemo(function(){return"function"==typeof e?e(n):{...n,...e}},[n,e])}function a(e){let n;return n=e.disableParentContext?"function"==typeof e.components?e.components(s):e.components||s:r(e.components),i.createElement(o.Provider,{value:n},e.children)}}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.