* Modify to define isJestEachFunctionCall
* Modify to break ArrayExpression when parent is jest each function
* Add tests
* Update CHANGELOG.unreleased.md
* Fix comment
* Add pr number
* Update CHANGELOG.unreleased.md
* Remove hasNewLineInRange
* Modify to change logic for breaking jest each call function
* Modify to add logic for breaking ArrayExpression
* Modify to avoid mixed nested array
* Modify to remove changes for jest
* Update CHANGELOG.unreleased.md
* Update CHANGELOG.unreleased.md
* chore: upgrade Jest
* chore: update snapshots
* chore: lock down babel dependency using invalid syntax
* 2 args to test.skip
* use jest 22 for now
* Revert "2 args to test.skip"
This reverts commit 691fdc3f99e320f2303958f2b503f7b4c93fa455.
* remove snapshot name from matcher
* fix standalone tests skips
* Upgrade flow to 0.64
This also enables spread operator on jsx on the flow parser:
```js
<div>{...list}</div>
```
I had no idea it was even a thing.
I had to comment out a flow test that no longer parses, but it's no longer in the flow repo and the comment said that it shouldn't be working anyway so I don't think it's going to be a problem.
* Fix build script
* Added prettier layout for class extends and implements
* Added prettier layout for class extends and implements, fix with keeping it in online if it fits
* Added prettier layout for class extends and implements, fixed tests as a side change
* Extends implements comments in same line fix
* Extends implements comments in same line without ugly workaround
* added empty line to test typescript_class/extends_implements.ts
* If only one extends keep old behaviour
* Removed console logs
* Adding --stdin-filepath option in order to enable filetype inference from
stdin
* Fixing typo on the documentation
* Fixing typos - fixing some typos
* Restoring static lib files back since they are artifacts
* Fix TypeScript comment snapshot
* Add failing test for TypeScript method comments
* Remove trailing space in comment
* Add snapshot for comment with many lines
* Add TODO marking potential location for comment re-indentation
* Update snapshot
* Indent comments based on the parent node
* Only adjust indentation if the comment looks like a JSDoc comment
* Only strip leading spaces when adjusting comment indentation
* Update snapshot
* Add test to show incorrect indentation based on parent node
* Update snapshot
* Update snapshot
* Update comment indentation to not rely on the parent node
* Extract code for getting the indent size
* Add test where the parent indentation changes as well
* Fix lint warning regarding lexical declarations within case block
* Update lockfile
* Update snapshot
* Add test case for block comment inside of a method
* Replace spread operator with `concat`
* Use `align` instead of `addAlignmentToDoc`
* Add test for mismatched indentation within JSDoc comment
* Always add a leading space to subsequent lines in a JSDoc comment
* Refactor JSDoc comment printing into a separate function
* Remove unneeded `align`
* Replace `forEach` with `map` for better style
* Only `trimLeft` when the end comment token is on the last line of the comment
* Remove unneeded `docBuilders`
* Add tests for JSDoc comments in JSX
* Update snapshots
* Use printPropertyKey function to print keys in object type property in TS and Flow
* Remove flow test modification
* Add tests for new object key cases
* Add new test file
* Fix some styles
* Allow JSX lines to be recombined
* Add test case for `<br />` breaking expression
* Fix issue where JSX whitespace could be dropped
* Newlines were incorrectly being preserved when JSX contained text
This tweaks our JSX formatting to only put a JSX whitespace `{" "}` on a line by itself when it comes before or after a multiline element.
When preceding a text or single line element it appear on the same line as that element.
There can often be something that breaks inside of `extends` so it's looking weird to break twice. It now only breaks on `implements` and make sure to put each element on its own line.
Fixes#1520
This keeps being requested and we're not using it at Facebook, so I don't particularly care which way it should be printed. We now force multiline if there's at least one declaration with a value. We don't want to break all the variables that are just declared.
Fixes#1607
* Add new fill primitive and use it to wrap text in JSX
This adds a new `fill` primitive that can be used to fill lines with as much code as possible before moving to a new line with the same indentation.
It is used here layout JSX children. This gives us nicer wrapping for JSX elements containings lots of text interspersed with tags.
* Quick fix for jsx whitespace regressions
* Fix a couple more bugs
* Tidy up the `fill` algorithm
Attempt to make the algorithm a little more regular, and improve the naming of variables to make it a little easier to understand (I hope!).
* Small tidy up of JSX whitespace declarations
* Remove unnecessary code
It turns out that `children` is only used in the case when the element is printed on a single line, in which case all the types of JSX whitespaces behave the same, so we don't need to special case leading/trailing/solitary whitespace.
* A little more tidy up based on PR feedback
* Fix up tests after rebasing
* Make it explicit that we keep multiple consecutive spaces
* Add an explanatory comment
* Fix broken snapshot in master
* Ignore existing commands when deciding whether content will fit when using fill
* Fix a bug where children would get incorrectly filled onto a line
* Tidy up JSX whitespace names
As I was debugging #1248, I found out that the code to fix was actually making things worse. The other two branches are for decorators and deleting some random value of a function. I ran all the tests and the flow object is actually now preserving empty lines and didn't change anything else.
I'd rather remove all those and if something comes up then fix it properly upstream than having those crutches that we don't know why they exist anymore.
I'm unclear whether anyone was ever confused by this but the eslint page is kind of compelling
```js
// The intent is not clear
var x = a => 1 ? 2 : 3;
// Did the author mean this
var x = function (a) { return 1 ? 2 : 3 };
// Or this
var x = a <= 1 ? 2 : 3;
```
Adding a parenthesis makes it valid with `{"allowParens": true}` rule. Note that if this option is not enabled, the code would not pass lint in the first place.
Sosuke Suzuki