Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
The following dependencies have been updated:
eslint-plugin-jest
in/
from "21.4.0" to "21.4.1"prettier
in/
from "1.8.2" to "1.9.0"Details
Dependencies.io has updated
eslint-plugin-jest
(a npm dependency in/
) from "21.4.0" to "21.4.1".21.4.1
21.4.1 (2017-12-05)
Bug Fixes
Dependencies.io has updated
prettier
(a npm dependency in/
) from "1.8.2" to "1.9.0".1.9.0
This release adds an option for arrow function parens in arguments, support for the new JSX fragment syntax (
<>
), support for.editorconfig
files, and nice additions to our GraphQL and Markdown support.Highlights
JavaScript
Option to add parens in arrow function arguments (#3324) by rattrayalex and suchipi
When printing arrow functions, Prettier omitted parens around the arguments if they weren’t strictly necessary, like so:
This lead to the most commented thread in our issue tracker. Prettier now has the
--arrow-parens
option (arrowParens
in the config) that can assume two values today:"avoid"
- (default) preserve the behavior that omits parens when possible"always"
- always includes parensJSX fragment syntax (#3237) by duailibe
Prettier will now recognize and format JSX with the new fragment syntax, like the code below:
Fix slow formatting long texts in JSX (#3268, #3273) by duailibe
We received feedback that formatting a JSX file with a really long text (~1000 lines) was really slow and noticed there was two performance bottlenecks in our
fill
primitive, which prints text until it reaches the print width and then insert a line break.Markdown
Add an option to preserve text line breaks (#3340) by ikatyang
After the release of our Markdown support, we received feedback that breaking text to respect the print width could affect some renderers that could be sensitive to line breaks. In 1.8.2 we released a new option
proseWrap: false
that would print a paragraph in a single line, and users would rely on the "soft wrapping" feature of editors.In 1.9 we are releasing a new option
proseWrap: "preserve"
which will respect the original line breaks of text, and lets the users decide where the text should break.[WARNING]
proseWrap
with boolean value is deprecated, use"always"
,"never"
or"preserve"
instead.[BREAKING CHANGE]
proseWrap
option now defaults to"preserve"
as some renderers are linebreak-sensitive.GraphQL
Support top-level interpolations (#3370) by lydell
When GraphQL support was released, Prettier did not support interpolation so it would skip formatting if any interpolations were present, because interpolations make formatting very difficult. While that works well for the most part, users of the Apollo Client were missing out on Prettier’s GraphQL support sometimes, because Apollo Client uses interpolation to share fragments between queries. The good news is that only top-level interpolations are allowed, and that was way easier to add support for in Prettier.
In 1.9 we format GraphQL queries with top-level interpolation:
(Prettier will continue to skip formatting if the interpolation is inside a query or mutation or so.)
Preserve intentional new lines in GraphQL (#3252) by duailibe
Prettier will now respect intentional line breaks inside GraphQL queries (but limit to 1), where before it would remove them.
CSS
Don't lowercase element names and attribute names in selectors (#3317) by lydell
CSS is mostly case insensitive, so Prettier has been lowercasing stuff for a while to keep things consistent. Turns out we overlooked a detail in the CSS spec. Element and attribute names in selectors depend on the markup language: In HTML they are case insensitive, but in SVG (XML) they are not. Previously Prettier would incorrectly lowercase element and attribute names, but now we don’t anymore.
Configuration
Add EditorConfig support (#3255) by josephfrazier
It's taken a while, but Prettier will finally respect your
.editorconfig
file. This includes:indent_style
indent_size
/tab_width
max_line_length
The
prettier
CLI respects.editorconfig
by default, but you can opt out with--no-editorconfig
.However, the API doesn't respect
.editorconfig
by default, in order to avoid potential editor integration issues (see here for details). To opt in, addeditorconfig: true
to theprettier.resolveConfig
options.Other changes
JavaScript
Don't break simple elements in JSX (#3250) by duailibe
Prettier won't break an element with no attributes anymore, keeping elements like
<br />
as an unit.Don't break identifiers inside template literals expressions (#3299) by duailibe
In the previous release we tried a new strategy of breaking template literals with expressions inside to respect the print width. We've received feedback that for some cases it was actually preferred that it would exceed print width than breaking in multiple lines.
From now on, template literals expressions that contain a single identifier won't break anymore:
Fix formatting of comment inside arrow function (#3334) by jackyho112
Fixes an edge case where Prettier was moving comments around breaking tools like Webpack:
Fix printing of comments around decorators and class properties (#3382) by azz
There was a case where comments between a decorator and a class property were moved to an invalid position.
Flow
Do not break on empty type parameters (#3281) by Vjeux
It won't break empty type parameters (
foo: Type<>
) anymore.Add support for flow mixins when using babylon (#3391) by bakkot
We were accidentally dropping flow mixins, this has been fixed, but only for the
babylon
parser.TypeScript
Don't print a trailing comma after object rest spread (#3313) by duailibe
This was inconsistent with JavaScript and Flow, Prettier won't print a trailing comma in the following cases, when using the TypeScript parser:
Print parens around type assertions for decorators (#3329) by azz
We were omitting parens around type assertions inside decorators:
Markdown
Don't break
inlineCode
(#3230) by ikatyangPrettier won't break text inside
inlineCode
meaning it will only break of after it.No extra whitespace between non-CJK and CJK-punctuation and vice-versa (#3244, #3249) by ikatyang
Fixes cases where Prettier would insert extra whitespace like in the following examples:
Escape all emphasis-like text (#3246) by ikatyang
Fixes the case where
\_\_text\_\_
would be formatted as__text__
.Handle punctuation variants (#3254) by ikatyang
Prettier now considers not only ASCII punctuation characters but Unicode as well.
Support TOML front matter (#3290) by ikatyang
We already supported YAML in the front matter of Markdown files and we added the TOML format as well, since some static site generators support it.
Only indent the first non-list node in checkbox list item (#3297) by ikatyang
Fixes a bug where it would indent lines after a list when it shouldn't:
would become:
Preserve non-breaking whitespaces (#3327) by ikatyang
Non-breaking whitespaces are useful to keep words separated by spaces together in the same line (i.e. number and units or multi-word product names). Prettier was wrongfully converting them to regular whitespaces.
Do not break before special prefix (#3347) by ikatyang
Fixes a bug where Prettier could break text if it went over the print width right before a number followed by
.
which would be parsed as a numbered list:Omit semicolon in simple JSX expressions (#3330) by sapegin
Prettier will omit the semicolon (before and after) inside code samples if it's a simple JSX expression: