vitalif-js
/
prettier
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Release 1.17.0

master
Lucas Duailibe 2019-04-12 17:35:23 -03:00
parent 6ae41067cf
commit 55abeb2108
11 changed files with 66 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE/formatting.md vendored
View File

@ -26,7 +26,7 @@ Tip! Don't write this stuff manually.
-->
**Prettier 1.16.4**
**Prettier 1.17.0**
[Playground link](https://prettier.io/playground/#.....)
```sh
# Options (if any):

2
.github/ISSUE_TEMPLATE/integration.md vendored
View File

@ -19,7 +19,7 @@ BEFORE SUBMITTING AN ISSUE:
-->
**Environments:**
- Prettier Version: 1.16.4
- Prettier Version: 1.17.0
- Running Prettier via: <!-- CLI, Node.js API, Browser API, etc. -->
- Runtime: <!-- Node.js v6, Chrome v67, etc. -->
- Operating System: <!-- Windows, Linux, macOS, etc. -->

6
CHANGELOG.md
View File

@ -1,3 +1,9 @@
# 1.17.0
[diff](https://github.com/prettier/prettier/compare/1.16.2...1.17.0)
🔗 [Release Notes](https://prettier.io/blog/2019/04/12/1.17.0.html)
# 1.16.4
[diff](https://github.com/prettier/prettier/compare/1.16.3...1.16.4)

2
package.json
View File

@ -1,6 +1,6 @@
{
"name": "prettier",
"version": "1.17.0-dev",
"version": "1.17.0",
"description": "Prettier is an opinionated code formatter",
"bin": {
"prettier": "./bin/prettier.js"

29
website/versioned_docs/version-stable/configuration.md
View File

@ -92,6 +92,35 @@ overrides:
`files` is required for each override, and may be a string or array of strings. `excludeFiles` may be optionally provided to exclude files for a given rule, and may also be a string or array of strings.
## Sharing configurations
Sharing a Prettier configuration is simple: just publish a module that exports a configuration object, say `@company/prettier-config`, and reference it in your `package.json`:
```json
{
"name": "my-cool-library",
"version": "9000.0.1",
"prettier": "@company/prettier-config"
}
```
If you don't want to use `package.json`, you can use any of the supported extensions to export a string, e.g. `.prettierrc.json`:
```json
"@company/prettier-config"
```
An example configuration repository is available [here](https://github.com/azz/prettier-config).
> Note: This method does **not** offer a way to _extend_ the configuration to overwrite some properties from the shared configuration. If you need to do that, import the file in a `.prettierrc.js` file and export the modifications, e.g:
>
> ```js
> module.exports = {
> ...require("@company/prettier-config"),
> semi: false
> };
> ```
## Setting the [parser](options.md#parser) option
By default, Prettier automatically infers which parser to use based on the input file extension. Combined with `overrides` you can teach Prettier how to parse files it does not recognize.

66
website/versioned_docs/version-stable/eslint.md
View File

@ -1,66 +0,0 @@
---
id: version-stable-eslint
title: Integrating with ESLint
original_id: eslint
---
If you are using ESLint, integrating Prettier to your workflow is straightforward.
There are two different ways you might want to integrate Prettier into ESLint. You may enable either one separately, or use both together.
## Use ESLint to run Prettier
If you're already running ESLint in your project and would like to do all of your style checking with a single command execution, you can ask ESLint to run Prettier for you.
Just add Prettier as an ESLint rule using [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier).
```bash
yarn add --dev prettier eslint-plugin-prettier
```
.eslintrc.json:
```json
{
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
}
}
```
## Turn off ESLint's formatting rules
Whether you run Prettier via ESLint or run both tools separately, you probably only want to hear about each formatting issue once, and you especially don't want ESLint to complain about formatting "issues" which are simply a different preference than what Prettier does.
So you'll probably want to disable the conflicting rules (while keeping around other rules that Prettier doesn't care about). The easiest way to do this is to use [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier). It's a one liner that can be added on-top of any existing ESLint configuration.
```bash
yarn add --dev eslint-config-prettier
```
.eslintrc.json:
```json
{
"extends": ["prettier"]
}
```
There are a few rules that this disables that you may want to turn back on as long as you don't use them with particular options which conflict with Prettier. See [the docs](https://github.com/prettier/eslint-config-prettier#special-rules) for details.
## Use both
`eslint-plugin-prettier` exposes a `"recommended"` configuration that turns on both `eslint-plugin-prettier` and `eslint-config-prettier`, all you need in your `.eslintrc.json` is:
```json
{
"extends": ["plugin:prettier/recommended"]
}
```
Remember to install both `eslint-plugin-prettier` and `eslint-config-prettier`:
```bash
yarn add --dev eslint-plugin-prettier eslint-config-prettier
```

19
website/versioned_docs/version-stable/options.md
View File

@ -70,6 +70,20 @@ See the [strings rationale](rationale.md#strings) for more information.
| ------- | ---------------- | --------------------- |
| `false` | `--single-quote` | `singleQuote: <bool>` |
## Quote Props
Change when properties in objects are quoted.
Valid options:
- `"as-needed"` - Only add quotes around object properties where required.
- `"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&#124;consistent&#124;preserve></code> | <code>quoteProps: "<as-needed&#124;consistent&#124;preserve>"</code> |
## JSX Quotes
Use single quotes instead of double quotes in JSX.
@ -184,7 +198,7 @@ Valid options:
- `"babel"` (via [@babel/parser](https://github.com/babel/babel/tree/master/packages/babel-parser)) _Named `"babylon"` until v1.16.0_
- `"babel-flow"` (Same as `"babel"` but enables Flow parsing explicitly to avoid ambiguity) _First available in v1.16.0_
- `"flow"` (via [flow-parser](https://github.com/facebook/flow/tree/master/src/parser))
- `"typescript"` (via [typescript-estree](https://github.com/JamesHenry/typescript-estree)) _First available in v1.4.0_
- `"typescript"` (via [@typescript-eslint/typescript-estree](https://github.com/typescript-eslint/typescript-eslint)) _First available in v1.4.0_
- `"css"` (via [postcss-scss](https://github.com/postcss/postcss-scss) and [postcss-less](https://github.com/shellscape/postcss-less), autodetects which to use) _First available in v1.7.1_
- `"scss"` (same parsers as `"css"`, prefers postcss-scss) _First available in v1.7.1_
- `"less"` (same parsers as `"css"`, prefers postcss-less) _First available in v1.7.1_
@ -197,6 +211,7 @@ Valid options:
- `"html"` (via [angular-html-parser](https://github.com/ikatyang/angular-html-parser/tree/master/packages/angular-html-parser)) _First available in 1.15.0_
- `"vue"` (same parser as `"html"`, but also formats vue-specific syntax) _First available in 1.10.0_
- `"angular"` (same parser as `"html"`, but also formats angular-specific syntax via [angular-estree-parser](https://github.com/ikatyang/angular-estree-parser)) _First available in 1.15.0_
- `"lwc"` (same parser as `"html"`, but also formats LWC-specific syntax for unquoted template attributes) _First available in 1.17.0_
- `"yaml"` (via [yaml](https://github.com/eemeli/yaml) and [yaml-unist-parser](https://github.com/ikatyang/yaml-unist-parser)) _First available in 1.14.0_
[Custom parsers](api.md#custom-parser-api) are also supported. _First available in v1.5.0_
@ -306,7 +321,7 @@ It also converts mixed line endings within one file to what it finds at the end
When people collaborate on a project from different operating systems, it becomes easy to end up with mixed line endings in the central git repository.
It is also possible for Windows users to accidentally change line endings in an already committed file from `LF` to `CRLF`.
Doing so produces a large `git diff`, and if it get unnoticed during code review, all line-by-line history for the file (`git blame`) gets lost.
Doing so produces a large `git diff`, and if it goes unnoticed during code review, all line-by-line history for the file (`git blame`) gets lost.
If you want to make sure that your git repository only contains Linux-style line endings in files covered by Prettier:

7
website/versioned_docs/version-stable/plugins.md
View File

@ -12,7 +12,9 @@ Plugins are ways of adding new languages to Prettier. Prettier's own implementat
## Using Plugins
Plugins are automatically loaded if you have them installed in the same `node_modules` directory where `prettier` is located. Plugin package names must start with `@prettier/plugin-` or `prettier-plugin-` to be registered.
Plugins are automatically loaded if you have them installed in the same `node_modules` directory where `prettier` is located. Plugin package names must start with `@prettier/plugin-` or `prettier-plugin-` or `@<scope>/prettier-plugin-` to be registered.
> `<scope>` should be replaced by a name, read more about [NPM scope](https://docs.npmjs.com/misc/scope.html).
When plugins cannot be found automatically, you can load them with:
@ -34,7 +36,7 @@ When plugins cannot be found automatically, you can load them with:
});
```
Prettier expects each of `pluginSearchDirs` to contain `node_modules` subdirectory, where `@prettier/plugin-*` and `prettier-plugin-*` will be searched. For instance, this can be your project directory or the location of global npm modules.
Prettier expects each of `pluginSearchDirs` to contain `node_modules` subdirectory, where `@prettier/plugin-*`, `@*/prettier-plugin-*` and `prettier-plugin-*` will be searched. For instance, this can be your project directory or the location of global npm modules.
Providing at least one path to `--plugin-search-dir`/`pluginSearchDirs` turns off plugin autoloading in the default directory (i.e. `node_modules` above `prettier` binary).
@ -52,6 +54,7 @@ Providing at least one path to `--plugin-search-dir`/`pluginSearchDirs` turns of
- [`prettier-plugin-java`](https://github.com/jhipster/prettier-java) by [**@JHipster**](https://github.com/jhipster)
- [`prettier-plugin-pg`](https://github.com/benjie/prettier-plugin-pg) by [**@benjie**](https://github.com/benjie)
- [`prettier-plugin-solidity`](https://github.com/prettier-solidity/prettier-plugin-solidity) by [**@mattiaerre**](https://github.com/mattiaerre)
- [`prettier-plugin-svelte`](https://github.com/UnwrittenFun/prettier-plugin-svelte) by [**@UnwrittenFun**](https://github.com/UnwrittenFun)
- [`prettier-plugin-toml`](https://github.com/bd82/toml-tools/tree/master/packages/prettier-plugin-toml) by [**@bd82**](https://github.com/bd82)
## Developing Plugins

21
website/versioned_docs/version-stable/precommit.md
View File

@ -8,28 +8,15 @@ You can use Prettier with a pre-commit tool. This can re-format your files that
## Option 1. [lint-staged](https://github.com/okonet/lint-staged)
**Use Case:** Useful for when you need to use other tools on top of Prettier (e.g. ESLint)
**Use Case:** Useful for when you want to use other code quality tools along with Prettier (e.g. ESLint, Stylelint, etc.) or if you need support for partially staged files (`git add --patch`).
Install it along with [husky](https://github.com/typicode/husky):
_Make sure Prettier is installed and is in your `devDependencies` before you proceed._
```bash
yarn add lint-staged husky --dev
npx mrm lint-staged
```
and add this config to your `package.json`:
```json
{
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,css,md}": ["prettier --write", "git add"]
}
}
```
This will install [husky](https://github.com/typicode/husky) and [lint-staged](https://github.com/okonet/lint-staged), then add a configuration to the project’s `package.json` that will automatically format supported files in a pre-commit hook.
See https://github.com/okonet/lint-staged#configuration for more details about how you can configure lint-staged.

2
website/versioned_docs/version-stable/rationale.md
View File

@ -265,7 +265,7 @@ Secondly, [the alternate formatting makes it easier to edit the JSX](https://git
When it comes to the _contents_ of comments, Prettier can’t do much really. Comments can contain everything from prose to commented out code and ASCII diagrams. Since they can contain anything, Prettier can’t 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 `*`), which Prettier can fix the indentation of.
Then there’s the question of _where_ to put the comments. Turns out this is a really difficult problem. Prettier tries it best to keep your comments roughly where they where, but it’s no easy task because comments can be placed almost anywhere.
Then there’s the question of _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’s no easy task because comments can be placed almost anywhere.
Generally, you get the best results when placing comments **on their own lines,** instead of at the end of lines. Prefer `// eslint-disable-next-line` over `// eslint-disable-line`.

2
website/versioned_sidebars/version-stable-sidebars.json
View File

@ -15,7 +15,7 @@
"version-stable-plugins",
"version-stable-precommit",
"version-stable-watching-files",
"version-stable-eslint",
"version-stable-integrating-with-linters",
"version-stable-ignore"
],
"Configuring Prettier": [