Migrate from Docusaurus 1 to Docusaurus 3 (#17043)
Co-authored-by: fisker Cheung <lionkay@gmail.com>
This commit is contained in:
1 parent
3e2f487049
commit
6a612520bc
119 files changed
+9687
-7789
No files matched your search
+5
-1
@@ -177,6 +177,10 @@ await format("lodash ( )", {
|
||||
// -> "_();\n"
|
||||
```
|
||||
|
||||
> Note: Overall, doing codemods this way isn’t recommended. Prettier uses the location data of AST nodes for many things like preserving blank lines and attaching comments. When the AST is modified after the parsing, the location data often gets out of sync, which may lead to unpredictable results. Consider using [jscodeshift](https://github.com/facebook/jscodeshift) if you need codemods.
|
||||
:::note
|
||||
|
||||
Overall, doing codemods this way isn’t recommended. Prettier uses the location data of AST nodes for many things like preserving blank lines and attaching comments. When the AST is modified after the parsing, the location data often gets out of sync, which may lead to unpredictable results. Consider using [jscodeshift](https://github.com/facebook/jscodeshift) if you need codemods.
|
||||
|
||||
:::
|
||||
|
||||
As part of the removed Custom parser API, it was previously possible to pass a path to a module exporting a `parse` function via the `--parser` option. Use the `--plugin` CLI option or the `plugins` API option instead to [load plugins](plugins.md#using-plugins).
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 230 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 100 KiB |
+1
-1
@@ -18,7 +18,7 @@ Required options:
|
||||
|
||||
- **[`parser`](options.md#parser) (or [`filepath`](options.md#file-path))**: One of these options has to be specified for Prettier to know which parser to use.
|
||||
|
||||
- **`plugins`**: Unlike the `format` function from the [Node.js-based API](api.md#prettierformatsource--options), this function doesn’t load plugins automatically. The `plugins` option is required because all the parsers included in the Prettier package come as plugins (for reasons of file size). These plugins are files in <https://unpkg.com/browse/prettier@%PRETTIER_VERSION%/plugins/>. Note that `estree` plugin should be loaded when printing JavaScript, TypeScript, Flow, or JSON.
|
||||
- **`plugins`**: Unlike the `format` function from the [Node.js-based API](api.md#prettierformatsource-options), this function doesn’t load plugins automatically. The `plugins` option is required because all the parsers included in the Prettier package come as plugins (for reasons of file size). These plugins are files in [https://unpkg.com/browse/prettier@%PRETTIER_VERSION%/plugins](https://unpkg.com/browse/prettier@%PRETTIER_VERSION%/plugins). Note that `estree` plugin should be loaded when printing JavaScript, TypeScript, Flow, or JSON.
|
||||
|
||||
You need to load the ones that you’re going to use and pass them to `prettier.format` using the `plugins` option.
|
||||
|
||||
|
||||
+20
-4
@@ -9,7 +9,11 @@ Use the `prettier` command to run Prettier from the command line.
|
||||
prettier [options] [file/dir/glob ...]
|
||||
```
|
||||
|
||||
> To run your locally installed version of Prettier, prefix the command with `npx` or `yarn` (if you use Yarn), i.e. `npx prettier --help`, or `yarn prettier --help`.
|
||||
:::note
|
||||
|
||||
To run your locally installed version of Prettier, prefix the command with `npx` or `yarn` (if you use Yarn), i.e. `npx prettier --help`, or `yarn prettier --help`.
|
||||
|
||||
:::
|
||||
|
||||
To format a file in-place, use `--write`. (Note: This overwrites your files!)
|
||||
|
||||
@@ -29,9 +33,17 @@ A more complicated example:
|
||||
prettier docs package.json "{app,__{tests,mocks}__}/**/*.js" --write --single-quote --trailing-comma all
|
||||
```
|
||||
|
||||
> Don’t forget the **quotes** around the globs! The quotes make sure that Prettier CLI expands the globs rather than your shell, which is important for cross-platform usage.
|
||||
:::warning
|
||||
|
||||
> It’s better to use a [configuration file](configuration.md) for formatting options like `--single-quote` and `--trailing-comma` instead of passing them as CLI flags. This way the Prettier CLI, [editor integrations](editors.md), and other tooling can all know what options you use.
|
||||
Don’t forget the **quotes** around the globs! The quotes make sure that Prettier CLI expands the globs rather than your shell, which is important for cross-platform usage.
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
It’s better to use a [configuration file](configuration.md) for formatting options like `--single-quote` and `--trailing-comma` instead of passing them as CLI flags. This way the Prettier CLI, [editor integrations](editors.md), and other tooling can all know what options you use.
|
||||
|
||||
:::
|
||||
|
||||
## File patterns
|
||||
|
||||
@@ -222,7 +234,11 @@ Running Prettier without `--cache` will delete the cache.
|
||||
|
||||
Also, since the cache file is stored in `./node_modules/.cache/prettier/.prettier-cache`, so you can use `rm ./node_modules/.cache/prettier/.prettier-cache` to remove it manually.
|
||||
|
||||
> Plugins version and implementation are not used as cache keys. We recommend that you delete the cache when updating plugins.
|
||||
:::warning
|
||||
|
||||
Plugins version and implementation are not used as cache keys. We recommend that you delete the cache when updating plugins.
|
||||
|
||||
:::
|
||||
|
||||
## `--cache-location`
|
||||
|
||||
|
||||
@@ -13,7 +13,11 @@ You can configure Prettier via (in order of precedence):
|
||||
- A `.prettierrc.cjs`, `prettier.config.cjs`, `.prettierrc.cts`, or `prettier.config.cts` file that exports an object using `module.exports`.
|
||||
- A `.prettierrc.toml` file.
|
||||
|
||||
> TypeScript configuration files support requires [additional setup](#typescript-configuration-files)
|
||||
:::info
|
||||
|
||||
TypeScript configuration files support requires [additional setup](#typescript-configuration-files)
|
||||
|
||||
:::
|
||||
|
||||
The configuration file will be resolved starting from the location of the file being formatted, and searching up the file tree until a config file is (or isn’t) found.
|
||||
|
||||
@@ -215,7 +219,7 @@ You can also switch to the `flow` parser instead of the default `babel` for .js
|
||||
|
||||
## Configuration Schema
|
||||
|
||||
If you’d like a JSON schema to validate your configuration, one is available here: <https://json.schemastore.org/prettierrc>.
|
||||
If you’d like a JSON schema to validate your configuration, one is available here: [https://json.schemastore.org/prettierrc](https://json.schemastore.org/prettierrc).
|
||||
|
||||
## EditorConfig
|
||||
|
||||
|
||||
@@ -7,10 +7,10 @@ title: For Enterprise
|
||||
|
||||
Tidelift is working with the maintainers of Prettier and thousands of other open source projects to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.
|
||||
|
||||
<a class="button" href="https://tidelift.com/subscription/pkg/npm-prettier?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Learn more</a>
|
||||
<a class="button" href="https://tidelift.com/subscription/request-a-demo?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Request a demo</a>
|
||||
<a class="button button--primary" href="https://tidelift.com/subscription/pkg/npm-prettier?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Learn more</a>
|
||||
<a class="button button--primary" href="https://tidelift.com/subscription/request-a-demo?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Request a demo</a>
|
||||
|
||||
<br>
|
||||
<br />
|
||||
|
||||
### Enterprise-ready open source software—managed for you
|
||||
|
||||
@@ -44,5 +44,5 @@ Tidelift works with GitHub, GitLab, BitBucket, and more. We support every cloud
|
||||
|
||||
The end result? All of the capabilities you expect from commercial-grade software, for the full breadth of open source you use. That means less time grappling with esoteric open source trivia, and more time building your own applications—and your business.
|
||||
|
||||
<a class="button" href="https://tidelift.com/subscription/pkg/npm-prettier?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Learn more</a>
|
||||
<a class="button" href="https://tidelift.com/subscription/request-a-demo?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Request a demo</a>
|
||||
<a class="button button--primary" href="https://tidelift.com/subscription/pkg/npm-prettier?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Learn more</a>
|
||||
<a class="button button--primary" href="https://tidelift.com/subscription/request-a-demo?utm_source=npm-prettier&utm_medium=referral&utm_campaign=enterprise">Request a demo</a>
|
||||
+2
-2
@@ -51,9 +51,9 @@ Prettier enforces a consistent code **style** (i.e. code formatting that won’t
|
||||
|
||||
If you want to learn more, these two conference talks are great introductions:
|
||||
|
||||
[](https://www.youtube.com/watch?v=hkfBvpEfWdA)
|
||||
[](https://www.youtube.com/watch?v=hkfBvpEfWdA)
|
||||
|
||||
[](https://www.youtube.com/watch?v=0Q4kUNx85_4)
|
||||
[](https://www.youtube.com/watch?v=0Q4kUNx85_4)
|
||||
|
||||
#### Footnotes
|
||||
|
||||
|
||||
+102
-51
@@ -3,34 +3,41 @@ id: install
|
||||
title: Install
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
First, install Prettier locally:
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--npm-->
|
||||
<Tabs groupId="package-manager">
|
||||
<TabItem value="npm">
|
||||
|
||||
```bash
|
||||
npm install --save-dev --save-exact prettier
|
||||
```
|
||||
|
||||
<!--yarn-->
|
||||
</TabItem>
|
||||
<TabItem value="yarn">
|
||||
|
||||
```bash
|
||||
yarn add --dev --exact prettier
|
||||
```
|
||||
|
||||
<!--pnpm-->
|
||||
</TabItem>
|
||||
<TabItem value="pnpm">
|
||||
|
||||
```bash
|
||||
pnpm add --save-dev --save-exact prettier
|
||||
```
|
||||
|
||||
<!--bun-->
|
||||
</TabItem>
|
||||
<TabItem value="bun">
|
||||
|
||||
```bash
|
||||
bun add --dev --exact prettier
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Then, create an empty config file to let editors and other tools know you are using Prettier:
|
||||
|
||||
@@ -51,48 +58,76 @@ Next, create a [.prettierignore](ignore.md) file to let the Prettier CLI and edi
|
||||
node --eval "fs.writeFileSync('.prettierignore','# Ignore artifacts:\nbuild\ncoverage\n')"
|
||||
```
|
||||
|
||||
> Tip! Prettier will follow rules specified in .gitignore if it exists in the same directory from which it is run. You can also base your .prettierignore on .eslintignore (if you have one).
|
||||
:::tip
|
||||
|
||||
> Another tip! If your project isn’t ready to format, say, HTML files yet, add `*.html`.
|
||||
Prettier will follow rules specified in .gitignore if it exists in the same directory from which it is run. You can also base your .prettierignore on .eslintignore (if you have one).
|
||||
|
||||
:::
|
||||
|
||||
:::tip[Another tip]
|
||||
|
||||
If your project isn’t ready to format, say, HTML files yet, add `*.html`.
|
||||
|
||||
:::
|
||||
|
||||
Now, format all files with Prettier:
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--npm-->
|
||||
<Tabs groupId="package-manager">
|
||||
<TabItem value="npm">
|
||||
|
||||
```bash
|
||||
npx prettier . --write
|
||||
```
|
||||
|
||||
> What is that `npx` thing? `npx` ships with `npm` and lets you run locally installed tools. We’ll leave off the `npx` part for brevity throughout the rest of this file!
|
||||
>
|
||||
> Note: If you forget to install Prettier first, `npx` will temporarily download the latest version. That’s not a good idea when using Prettier, because we change how code is formatted in each release! It’s important to have a locked down version of Prettier in your `package.json`. And it’s faster, too.
|
||||
:::info
|
||||
|
||||
<!--yarn-->
|
||||
What is that `npx` thing? `npx` ships with `npm` and lets you run locally installed tools. We’ll leave off the `npx` part for brevity throughout the rest of this file!
|
||||
|
||||
Note: If you forget to install Prettier first, `npx` will temporarily download the latest version. That’s not a good idea when using Prettier, because we change how code is formatted in each release! It’s important to have a locked down version of Prettier in your `package.json`. And it’s faster, too.
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="yarn">
|
||||
|
||||
```bash
|
||||
yarn prettier . --write
|
||||
```
|
||||
|
||||
> What is `yarn` doing at the start? `yarn prettier` runs the locally installed version of Prettier. We’ll leave off the `yarn` part for brevity throughout the rest of this file!
|
||||
:::info
|
||||
|
||||
<!--pnpm-->
|
||||
What is `yarn` doing at the start? `yarn prettier` runs the locally installed version of Prettier. We’ll leave off the `yarn` part for brevity throughout the rest of this file!
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="pnpm">
|
||||
|
||||
```bash
|
||||
pnpm exec prettier . --write
|
||||
```
|
||||
|
||||
> What is `pnpm` doing at the start? `pnpm prettier` runs the locally installed version of Prettier. We’ll leave off the `pnpm` part for brevity throughout the rest of this file!
|
||||
:::info
|
||||
|
||||
<!--bun-->
|
||||
What is `pnpm` doing at the start? `pnpm prettier` runs the locally installed version of Prettier. We’ll leave off the `pnpm` part for brevity throughout the rest of this file!
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="bun">
|
||||
|
||||
```bash
|
||||
bun prettier . --write
|
||||
```
|
||||
|
||||
> What is `bun` doing at the start? `bun prettier` runs the locally installed version of Prettier. We’ll leave off the `bun` part for brevity throughout the rest of this file!
|
||||
:::info
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
What is `bun` doing at the start? `bun prettier` runs the locally installed version of Prettier. We’ll leave off the `bun` part for brevity throughout the rest of this file!
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
`prettier --write .` is great for formatting everything, but for a big project it might take a little while. You may run `prettier --write app/` to format a certain directory, or `prettier --write app/components/Button.js` to format a certain file. Or use a _glob_ like `prettier --write "app/**/*.test.js"` to format all tests in a directory (see [fast-glob](https://github.com/mrmlnc/fast-glob#pattern-syntax) for supported glob syntax).
|
||||
|
||||
@@ -110,9 +145,13 @@ Formatting from the command line is a good way to get started, but you get the m
|
||||
|
||||
See [Editor Integration](editors.md) for how to set up your editor. If your editor does not support Prettier, you can instead [run Prettier with a file watcher](watching-files.md).
|
||||
|
||||
> **Note:** Don’t skip the regular local install! Editor plugins will pick up your local version of Prettier, making sure you use the correct version in every project. (You wouldn’t want your editor accidentally causing lots of changes because it’s using a newer version of Prettier than your project!)
|
||||
>
|
||||
> And being able to run Prettier from the command line is still a good fallback, and needed for CI setups.
|
||||
:::note
|
||||
|
||||
Don’t skip the regular local install! Editor plugins will pick up your local version of Prettier, making sure you use the correct version in every project. (You wouldn’t want your editor accidentally causing lots of changes because it’s using a newer version of Prettier than your project!)
|
||||
|
||||
And being able to run Prettier from the command line is still a good fallback, and needed for CI setups.
|
||||
|
||||
:::
|
||||
|
||||
## ESLint (and other linters)
|
||||
|
||||
@@ -128,42 +167,50 @@ For example, you can do the following to have Prettier run before each commit:
|
||||
|
||||
1. Install [husky](https://github.com/typicode/husky) and [lint-staged](https://github.com/okonet/lint-staged):
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--npm-->
|
||||
<Tabs groupId="package-manager">
|
||||
<TabItem value="npm">
|
||||
|
||||
```bash
|
||||
npm install --save-dev husky lint-staged
|
||||
npx husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','npx lint-staged\n')"
|
||||
```
|
||||
```bash
|
||||
npm install --save-dev husky lint-staged
|
||||
npx husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','npx lint-staged\n')"
|
||||
```
|
||||
|
||||
<!--yarn-->
|
||||
</TabItem>
|
||||
<TabItem value="yarn">
|
||||
|
||||
```bash
|
||||
yarn add --dev husky lint-staged
|
||||
npx husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','yarn lint-staged\n')"
|
||||
```
|
||||
```bash
|
||||
yarn add --dev husky lint-staged
|
||||
npx husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','yarn lint-staged\n')"
|
||||
```
|
||||
|
||||
> If you use Yarn 2, see https://typicode.github.io/husky/#/?id=yarn-2
|
||||
:::note
|
||||
|
||||
<!--pnpm-->
|
||||
If you use Yarn 2, see https://typicode.github.io/husky/#/?id=yarn-2
|
||||
|
||||
```bash
|
||||
pnpm add --save-dev husky lint-staged
|
||||
pnpm exec husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','pnpm exec lint-staged\n')"
|
||||
```
|
||||
:::
|
||||
|
||||
<!--bun-->
|
||||
</TabItem>
|
||||
<TabItem value="pnpm">
|
||||
|
||||
```bash
|
||||
bun add --dev husky lint-staged
|
||||
bunx husky init
|
||||
bun --eval "fs.writeFileSync('.husky/pre-commit','bunx lint-staged\n')"
|
||||
```
|
||||
```bash
|
||||
pnpm add --save-dev husky lint-staged
|
||||
pnpm exec husky init
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit','pnpm exec lint-staged\n')"
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
</TabItem>
|
||||
<TabItem value="bun">
|
||||
|
||||
```bash
|
||||
bun add --dev husky lint-staged
|
||||
bunx husky init
|
||||
bun --eval "fs.writeFileSync('.husky/pre-commit','bunx lint-staged\n')"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
2. Add the following to your `package.json`:
|
||||
|
||||
@@ -175,7 +222,11 @@ For example, you can do the following to have Prettier run before each commit:
|
||||
}
|
||||
```
|
||||
|
||||
> Note: If you use ESLint, make sure lint-staged runs it before Prettier, not after.
|
||||
:::note
|
||||
|
||||
If you use ESLint, make sure lint-staged runs it before Prettier, not after.
|
||||
|
||||
:::
|
||||
|
||||
See [Pre-commit Hook](precommit.md) for more information.
|
||||
|
||||
|
||||
@@ -3,9 +3,13 @@ id: option-philosophy
|
||||
title: Option Philosophy
|
||||
---
|
||||
|
||||
> Prettier has a few options because of history. **But we won’t add more of them.**
|
||||
>
|
||||
> Read on to learn more.
|
||||
:::info
|
||||
|
||||
Prettier has a few options because of history. **But we won’t add more of them.**
|
||||
|
||||
Read on to learn more.
|
||||
|
||||
:::
|
||||
|
||||
Prettier is not a kitchen-sink code formatter that attempts to print your code in any way you wish. It is _opinionated._ Quoting the [Why Prettier?](why-prettier.md) page:
|
||||
|
||||
|
||||
+46
-38
@@ -29,23 +29,27 @@ Valid options:
|
||||
- `"start"` - When binary expressions wrap lines, print operators at the start of new lines.
|
||||
- `"end"` - Default behavior; when binary expressions wrap lines, print operators at the end of previous lines.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | -------------------------------------------------------------- | ------------------------------------------------------------- |
|
||||
| `"end"` | <code>--experimental-operator-position <start|end></code> | <code>experimentalOperatorPosition: "<start|end>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | --------------------------------------------------------------- | -------------------------------------------------------------- |
|
||||
| `"end"` | <code>--experimental-operator-position \<start|end></code> | <code>experimentalOperatorPosition: "\<start|end>"</code> |
|
||||
|
||||
## Print Width
|
||||
|
||||
Specify the line length that the printer will wrap on.
|
||||
|
||||
> **For readability we recommend against using more than 80 characters:**
|
||||
>
|
||||
> In code styleguides, maximum line length rules are often set to 100 or 120. However, when humans write code, they don’t strive to reach the maximum number of columns on every line. Developers often use whitespace to break up long lines for readability. In practice, the average line length often ends up well below the maximum.
|
||||
>
|
||||
> Prettier’s printWidth option does not work the same way. It is not the hard upper allowed line length limit. It is a way to say to Prettier roughly how long you’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified printWidth.
|
||||
>
|
||||
> Remember, computers are dumb. You need to explicitly tell them what to do, while humans can make their own (implicit) judgements, for example on when to break a line.
|
||||
>
|
||||
> In other words, don’t try to use printWidth as if it was ESLint’s [max-len](https://eslint.org/docs/rules/max-len) – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.
|
||||
:::warning
|
||||
|
||||
**For readability we recommend against using more than 80 characters:**
|
||||
|
||||
In code styleguides, maximum line length rules are often set to 100 or 120. However, when humans write code, they don’t strive to reach the maximum number of columns on every line. Developers often use whitespace to break up long lines for readability. In practice, the average line length often ends well below the maximum.
|
||||
|
||||
Prettier’s printWidth option does not work the same way. It is not the hard upper allowed line length limit. It is a way to say to Prettier roughly how ng you’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified printWidth.
|
||||
|
||||
Remember, computers are dumb. You need to explicitly tell them what to do, while humans can make their own (implicit) judgements, for example on when break a line.
|
||||
|
||||
In other words, don’t try to use printWidth as if it was ESLint’s [max-len](https://eslint.org/docs/rules/max-len) – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.
|
||||
|
||||
:::
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | --------------------- | ------------------- |
|
||||
@@ -115,9 +119,9 @@ Valid options:
|
||||
- `"consistent"` - If at least one property in an object requires quotes, quote all properties.
|
||||
- `"preserve"` - Respect the input use of quotes in object properties.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------- |
|
||||
| `"as-needed"` | <code>--quote-props <as-needed|consistent|preserve></code> | <code>quoteProps: "<as-needed|consistent|preserve>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |
|
||||
| `"as-needed"` | <code>--quote-props \<as-needed|consistent|preserve></code> | <code>quoteProps: "\<as-needed|consistent|preserve>"</code> |
|
||||
|
||||
Note that Prettier never unquotes numeric property names in Angular expressions, TypeScript, and Flow because the distinction between string and numeric keys is significant in these languages. See: [Angular][quote-props-angular], [TypeScript][quote-props-typescript], [Flow][quote-props-flow]. Also Prettier doesn’t unquote numeric properties for Vue (see the [issue][quote-props-vue] about that).
|
||||
|
||||
@@ -146,9 +150,9 @@ Valid options:
|
||||
- `"es5"` - Trailing commas where valid in ES5 (objects, arrays, etc.). Trailing commas in type parameters in TypeScript and Flow.
|
||||
- `"none"` - No trailing commas.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ------------------------------------------------------ | ------------------------------------------------------ |
|
||||
| `"all"` | <code>--trailing-comma <all|es5|none></code> | <code>trailingComma: "<all|es5|none>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| `"all"` | <code>--trailing-comma \<all|es5|none></code> | <code>trailingComma: "\<all|es5|none>"</code> |
|
||||
|
||||
## Bracket Spacing
|
||||
|
||||
@@ -176,9 +180,9 @@ Valid options:
|
||||
- `"preserve"` - Keep as multi-line, if there is a newline between the opening brace and first property.
|
||||
- `"collapse"` - Fit to a single line when possible.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------ | --------------------------------------------------- | --------------------------------------------------- |
|
||||
| `"preserve"` | <code>--object-wrap <preserve|collapse></code> | <code>objectWrap: "<preserve|collapse>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------ | ---------------------------------------------------- | ---------------------------------------------------- |
|
||||
| `"preserve"` | <code>--object-wrap \<preserve|collapse></code> | <code>objectWrap: "\<preserve|collapse>"</code> |
|
||||
|
||||
## Bracket Line
|
||||
|
||||
@@ -217,7 +221,11 @@ Valid options:
|
||||
|
||||
## [Deprecated] JSX Brackets
|
||||
|
||||
_This option has been deprecated in v2.4.0, use --bracket-same-line instead_
|
||||
:::danger
|
||||
|
||||
This option has been deprecated in v2.4.0, use --bracket-same-line instead\_
|
||||
|
||||
:::
|
||||
|
||||
Put the `>` of a multi-line JSX element at the end of the last line instead of being alone on the next line (does not apply to self closing elements).
|
||||
|
||||
@@ -263,9 +271,9 @@ Valid options:
|
||||
- `"always"` - Always include parens. Example: `(x) => x`
|
||||
- `"avoid"` - Omit parens when possible. Example: `x => x`
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ---------- | ----------------------------------------------- | ----------------------------------------------- |
|
||||
| `"always"` | <code>--arrow-parens <always|avoid></code> | <code>arrowParens: "<always|avoid>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ---------- | ------------------------------------------------ | ------------------------------------------------ |
|
||||
| `"always"` | <code>--arrow-parens \<always|avoid></code> | <code>arrowParens: "\<always|avoid>"</code> |
|
||||
|
||||
At first glance, avoiding parentheses may look like a better choice because of less visual noise.
|
||||
However, when Prettier removes parentheses, it becomes harder to add type annotations, extra arguments or default values as well as making other changes.
|
||||
@@ -325,7 +333,7 @@ Valid options:
|
||||
|
||||
Note: the default value was `"babylon"` until v1.13.0.
|
||||
|
||||
Note: the Custom parser API has been removed in v3.0.0. Use [plugins](plugins.md) instead ([how to migrate](api.md#custom-parser-api)).
|
||||
Note: the Custom parser API has been removed in v3.0.0. Use [plugins](plugins.md) instead ([how to migrate](api.md#custom-parser-api-removed)).
|
||||
|
||||
<a name="filepath"></a>
|
||||
|
||||
@@ -397,9 +405,9 @@ Valid options:
|
||||
- `"never"` - Un-wrap each block of prose into one line.
|
||||
- `"preserve"` - Do nothing, leave prose as-is. _First available in v1.9.0_
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------ | ----------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
| `"preserve"` | <code>--prose-wrap <always|never|preserve></code> | <code>proseWrap: "<always|never|preserve>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| `"preserve"` | <code>--prose-wrap \<always|never|preserve></code> | <code>proseWrap: "\<always|never|preserve>"</code> |
|
||||
|
||||
## HTML Whitespace Sensitivity
|
||||
|
||||
@@ -415,9 +423,9 @@ Valid options:
|
||||
- `"strict"` - Whitespace (or the lack of it) around all tags is considered significant.
|
||||
- `"ignore"` - Whitespace (or the lack of it) around all tags is considered insignificant.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------- |
|
||||
| `"css"` | <code>--html-whitespace-sensitivity <css|strict|ignore></code> | <code>htmlWhitespaceSensitivity: "<css|strict|ignore>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
|
||||
| `"css"` | <code>--html-whitespace-sensitivity \<css|strict|ignore></code> | <code>htmlWhitespaceSensitivity: "\<css|strict|ignore>"</code> |
|
||||
|
||||
## Vue files script and style tags indentation
|
||||
|
||||
@@ -466,9 +474,9 @@ Valid options:
|
||||
- `"auto"` - Maintain existing line endings
|
||||
(mixed values within one file are normalised by looking at what’s used after the first line)
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ----------------------------------------------------------- | ---------------------------------------------------------- |
|
||||
| `"lf"` | <code>--end-of-line <lf|crlf|cr|auto></code> | <code>endOfLine: "<lf|crlf|cr|auto>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| ------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
|
||||
| `"lf"` | <code>--end-of-line \<lf|crlf|cr|auto></code> | <code>endOfLine: "\<lf|crlf|cr|auto>"</code> |
|
||||
|
||||
Setting `end_of_line` in an [`.editorconfig` file](https://editorconfig.org/) will configure Prettier’s end of line usage, unless overridden.
|
||||
|
||||
@@ -487,9 +495,9 @@ Valid options:
|
||||
- `"auto"` – Format embedded code if Prettier can automatically identify it.
|
||||
- `"off"` - Never automatically format embedded code.
|
||||
|
||||
| Default | CLI Override | API Override |
|
||||
| -------- | ----------------------------------------------------------- | ---------------------------------------------------------- |
|
||||
| `"auto"` | <code>--embedded-language-formatting=<off|auto></code> | <code>embeddedLanguageFormatting: "<off|auto>"</code> |
|
||||
| Default | CLI Override | API Override |
|
||||
| -------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
|
||||
| `"auto"` | <code>--embedded-language-formatting=\<off|auto></code> | <code>embeddedLanguageFormatting: "\<off|auto>"</code> |
|
||||
|
||||
## Single Attribute Per Line
|
||||
|
||||
|
||||
+5
-1
@@ -15,7 +15,11 @@ You can load plugins with:
|
||||
prettier --write main.foo --plugin=prettier-plugin-foo
|
||||
```
|
||||
|
||||
> Tip: You can set `--plugin` options multiple times.
|
||||
:::tip
|
||||
|
||||
You can set `--plugin` options multiple times.
|
||||
|
||||
:::
|
||||
|
||||
- The [API](api.md), via the `plugins` options:
|
||||
|
||||
|
||||
+13
-6
@@ -3,6 +3,9 @@ id: precommit
|
||||
title: Pre-commit Hook
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
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.
|
||||
|
||||
## Option 1. [lint-staged](https://github.com/okonet/lint-staged)
|
||||
@@ -53,8 +56,8 @@ Git-format-staged is used to run any formatter that can accept file content via
|
||||
|
||||
Git-format-staged requires Python v3 or v2.7. Python is usually pre-installed on Linux and macOS, but not on Windows. Use git-format-staged with [husky](https://github.com/typicode/husky):
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--npm-->
|
||||
<Tabs groupId="package-manager">
|
||||
<TabItem value="npm">
|
||||
|
||||
```bash
|
||||
npx husky init
|
||||
@@ -62,7 +65,8 @@ npm install --save-dev git-format-staged
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit', 'git-format-staged -f \'prettier --ignore-unknown --stdin --stdin-filepath \"{}\"\' .\n')"
|
||||
```
|
||||
|
||||
<!--yarn-->
|
||||
</TabItem>
|
||||
<TabItem value="yarn">
|
||||
|
||||
```bash
|
||||
yarn husky init
|
||||
@@ -70,7 +74,8 @@ yarn add --dev git-format-staged
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit', 'git-format-staged -f \'prettier --ignore-unknown --stdin --stdin-filepath \"{}\"\' .\n')"
|
||||
```
|
||||
|
||||
<!--pnpm-->
|
||||
</TabItem>
|
||||
<TabItem value="pnpm">
|
||||
|
||||
```bash
|
||||
pnpm exec husky init
|
||||
@@ -78,7 +83,8 @@ pnpm add --save-dev git-format-staged
|
||||
node --eval "fs.writeFileSync('.husky/pre-commit', 'git-format-staged -f \'prettier --ignore-unknown --stdin --stdin-filepath \"{}\"\' .\n')"
|
||||
```
|
||||
|
||||
<!--bun-->
|
||||
</TabItem>
|
||||
<TabItem value="bun">
|
||||
|
||||
```bash
|
||||
bunx husky init
|
||||
@@ -86,7 +92,8 @@ bun add --dev git-format-staged
|
||||
bun --eval "fs.writeFileSync('.husky/pre-commit', 'git-format-staged -f \'prettier --ignore-unknown --stdin --stdin-filepath \"{}\"\' .\n')"
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Add or remove file extensions to suit your project. Note that regardless of which extensions you list formatting will respect any `.prettierignore` files in your project.
|
||||
|
||||
|
||||
+10
-8
@@ -13,9 +13,9 @@ The first requirement of Prettier is to output valid code that has the exact sam
|
||||
|
||||
### Strings
|
||||
|
||||
Double or single quotes? Prettier chooses the one which results in the fewest number of escapes. `"It's gettin' better!"`, not `'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 [singleQuote](options.html#quotes) option).
|
||||
Double or single quotes? Prettier chooses the one which results in the fewest number of escapes. `"It's gettin' better!"`, not `'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 [singleQuote](/docs/options#quotes) option).
|
||||
|
||||
JSX has its own option for quotes: [jsxSingleQuote](options.html#jsx-quotes).
|
||||
JSX has its own option for quotes: [jsxSingleQuote](/docs/options#jsx-quotes).
|
||||
JSX 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).
|
||||
|
||||
Prettier maintains the way your string is escaped. For example, `"🙂"` won’t be formatted into `"\uD83D\uDE42"` and vice versa.
|
||||
@@ -79,11 +79,13 @@ const user = {
|
||||
[stylesheets]: https://github.com/prettier/prettier/issues/74#issuecomment-275262094
|
||||
[keyed methods]: https://github.com/prettier/prettier/pull/495#issuecomment-275745434
|
||||
|
||||
> #### ♻️ A note on formatting reversibility
|
||||
>
|
||||
> 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’t found and an urgent fix was needed. However, as a general strategy, Prettier avoids _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’s applied.
|
||||
>
|
||||
> What does **reversible** mean? Once an object literal becomes multiline, Prettier won’t 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.
|
||||
:::note[A note on formatting reversibility]
|
||||
|
||||
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’t found and an urgent fix was needed. However, as a general strategy, Prettier avoids _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’s applied.
|
||||
|
||||
What does **reversible** mean? Once an object literal becomes multiline, Prettier won’t 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.
|
||||
|
||||
:::
|
||||
|
||||
### Decorators
|
||||
|
||||
@@ -228,7 +230,7 @@ console.log("Running a background task")(async () => {
|
||||
|
||||
The [printWidth](options.md#print-width) 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’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified print width.
|
||||
|
||||
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 [Prettier doesn’t do](#what-prettier-is-_not_-concerned-about)). Or if you nest your code 50 levels deep your lines are of course going to be mostly indentation :)
|
||||
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 [Prettier doesn’t do](#what-prettier-is-not-concerned-about)). Or if you nest your code 50 levels deep your lines are of course going to be mostly indentation :)
|
||||
|
||||
Apart from that, there are a few cases where Prettier intentionally exceeds the print width.
|
||||
|
||||
|
||||
@@ -3,6 +3,9 @@ id: sharing-configurations
|
||||
title: Sharing configurations
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
In case you have many different projects, it can be helpful to have a **shared configuration** which can be used in all of them, instead of copy-pasting the same config for every project.
|
||||
|
||||
This page explains how to create, publish and consume a shareable config.
|
||||
@@ -71,32 +74,36 @@ npm publish
|
||||
|
||||
You first need to install your published configuration, for example:
|
||||
|
||||
<!--DOCUSAURUS_CODE_TABS-->
|
||||
<!--npm-->
|
||||
<Tabs groupId="package-manager">
|
||||
<TabItem value="npm">
|
||||
|
||||
```bash
|
||||
npm install --save-dev @username/prettier-config
|
||||
```
|
||||
|
||||
<!--yarn-->
|
||||
</TabItem>
|
||||
<TabItem value="yarn">
|
||||
|
||||
```bash
|
||||
yarn add --dev @username/prettier-config
|
||||
```
|
||||
|
||||
<!--pnpm-->
|
||||
</TabItem>
|
||||
<TabItem value="pnpm">
|
||||
|
||||
```bash
|
||||
pnpm add --save-dev @username/prettier-config
|
||||
```
|
||||
|
||||
<!--bun-->
|
||||
</TabItem>
|
||||
<TabItem value="bun">
|
||||
|
||||
```bash
|
||||
bun add --dev @username/prettier-config
|
||||
```
|
||||
|
||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Then, you can reference it in your `package.json`:
|
||||
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ Once it’s done, you can do a few things in your IDE. You can use the **Reforma
|
||||
|
||||
You can also configure WebStorm to run Prettier on save (_Cmd+S/Ctrl+S_) or use it as the default formatter (_Opt+Cmd+L/Ctrl+Alt+L_). For this, open _Preferences / Settings | Languages & Frameworks | JavaScript | Prettier_ and tick the corresponding checkbox: **On save** and/or **On ‘Reformat Code’** action.
|
||||
|
||||

|
||||

|
||||
|
||||
By default, WebStorm will apply formatting to all _.js, .ts, .jsx_, and _.tsx_ files that you’ve edited in your project. To apply the formatting to other file types, or to limit formatting to files located only in specific directories, you can customize the default configuration by using [glob patterns](https://github.com/isaacs/node-glob).
|
||||
|
||||
|
||||
Reference in new issue
Block a user