This avoids making it seems like it is indented by 4 characters instead of two. The downside is that if the condition is multi-line it's not going to be properly aligned, but I feel it's a better trade-offs. If you are doing nested ternaries, you usually have small conditions.
This commit updates `npm run format:all` to not only format .js files in
src/ and bin/, but also tests_config/ and scripts/, as well as all
jsfmt.spec.js files.
It also includes the result of running `npm run format:all`, except
changes to src/ and bin/.
This was added in order to follow some eslint rule but it's only confusing when it doesn't break, when it breaks the indentation makes it clear what is happening and you don't need parenthesis.
Fixes#1379
All of the discussions around ternaries are for the form
```js
cond1 ? elem1_if : cond2 ? elem2_if : elem_else
```
but some of them are for the form
```js
cond1 ? cond2 ? elem2_if : elem2_else : elem1_else
```
which is more rare and would be good to call out by adding parenthesis.
```js
cond1 ? (cond2 ? elem2_if : elem2_else) : elem1_else
```
Note that we only want parenthesis if it's written inline, otherwise the indentation is good enough to understand the flow:
```js
cond1
? cond2 ? elem2_if : elem2_else
: elem1_else
```
* Verify parsers against same snapshot
- Reworked run_spec, now accepts 3th optional array argument for
additional parsers to verify against
- Merged duplicate run_spec configs
- Removed duplicate snapshot data
* Formatted run_spec.js with prettier
* Fixed node4 incompatibility
* Revert "Remove mutation in `printBinaryishExpressions` (#1067)"
This reverts commit e7312ad7b2.
* Revert "Make it clear what parser was used in each snapshot (#1068)"
This reverts commit 4f7ae4815b.
* WIP immediate feedback
* typescript parser is drop-in replacement for flow parser
* Add new TypeScript Parser snapshots where drop-in replacement possible
* Snapshot updates after rebasing
* Remove unnecessary stripping of properties on TypeScript parser AST
* Remove annotated issues
* Move TS dependencies to dev for now
It turns out that the range is not inclusive. It incorrectly included a \n after and would expand way more objects than we intended to.
I found it while running prettier on the codebase.
I'll make 0.14.1 for this.
Another attempt at solving the issue where objects are not expanded the way people expect. If there's any new line in the original source, it's going to expand it. This gives more control to the user in how the objects should be formatted.
Fixes#74
Christopher Chedeau