We don't call the generic print on the BinaryExpression itself, so we need to manually print those comments. It's going to be useful for my work on the MemberExpression :)
It's actually not needed to use conditionalGroup as we can use ifBreak for it. I was able to do it just for cleanup and found out that it also fixed two of the bugs we have with comments. That's great :p
Fixes#485Fixes#486
Conditionals are very common in JSX and it is unfortunate that they take up so much vertical space in the current prettier.
This pull request does a few tweaks:
- It hugs ConditionalExpression (ternary) and LogicalExpression (&&) inside of `{}` in a jsx child, not an attribute
- It doesn't output parenthesis if your parent is a LogicalExpression (&&)
Fixes#317
Mobx is the only popular JavaScript library that I know about which uses decorators. They put things on the same line so we should follow their conventions.
The logic implemented here is the following: if there is one decorator, it's on the same line. If there is more than one, they are each on their own line.
Fixes#325
This was introduced by #314 where `line` should have been `softline`. By the way, I was going to propose renaming `line` to `line_or_space` and `softline` to `line_or_nothing` which should make it more explicit what is going on.
Fixes#461
Given the discussion on #296, it seems like there's debate between spaces around `{}` but no one puts spaces around `[]`. So changing the behavior to respect this.
The original intent of it was for `if then else` and `try catch` as they aren't likely to be empty, but it accidentally caught function bodys, which have many valid reasons to be empty. Let's special case those out.
We actually need this `;` for EmptyStatement, otherwise it applies to the next block of code. (Creating a label with an empty statement is completely useless, but it triggers a lot in the fuzz testing tool)
Fixes#376
We avoid adding a `;` for a variable declaration in for loop but this is only meant if the var declaration is inside of the `()` part of the for loop. Not if the body part.
Fixes#385
* Add tests for quotes
* Update test snapshots
* Output strings with the minimum amount of escaped quotes
* Update test snapshots
* Move tests/prettier/quotes.js into tests/quotes/strings.js
* Update test snapshots
- During the first iteration, we printed the unescaped values which let to printing invalid JavaScript characters and bad things like invisible characters.
- During the second iteration, we escaped everything, which generated valid JavaScript but you lost your emojis and chinese/cyrillic characters
In this iteration, which I hope will be the last one, we maintain the string exactly as encoded and only swap quotes. The swap quotes implementation is a bit convoluted but I think it works.
The previous API was inconsistent. The new one is
```js
--parser flow
--parser babylon
{parser: 'flow'}
{parser: 'babylon'}
```
if we ever want to add new parsers in the future it'll allow that more easily.
I put a console.log in parser.js in both functions and tested that the test suite worked both with and without the change in run_spec. I also tested that both the previous and new command line options are working.
At some point in the future we'll likely want to get rid of the old api but might as well keep supporting it so we don't break anyone for now.
- doc-printer.js is now the direct implementation of the Wadler paper
- doc-builders.js are a lot of utils to generate the IR the above file needs
- doc-utils.js are small utils to traverse list of docs.
It's annoying that there's a bug inside of the flow parser, I raised it internally. While this is getting fixed, we can workaround it. This now makes babylon properly escape JSXText.
I thought I didn't need to check the length but forgot that the rest argument is not in the list for class declaration. Now it doesn't crash anymore and there's a test...
The current output of
```js
[...a, ...b]
```
is
```js
[...a, , ...b]
```
because flow parses it as
```
ArrayExpression(SpreadExpression, null, SpreadExpression)
```
This is a bug in the flow parser. Until it gets fixed, we can workaround it by deleting the `null` after a `SpreadExpression`.
I copy and pasted the code for arrays which doesn't have this problem. Would be nice to come up with an abstraction for a list of stuff separated by commas. It happens a lot of time and right now it's duplicated everywhere.
Fixes#255
According to @mroch, "Flow is using CESU-8, not UTF-8. http://www.unicode.org/reports/tr26/ ". While this is being fixed in flow, we can easily work around it inside of prettier. The downside of this approach is that we can't convert those strings to single or double quotes anymore.
```js
for (;;);
function f() {}
```
The `;` was dropped meaning that the line right after was executed within the for loop which is not correct.
I tried to return `;` but it looks like
```js
for (;;)
;
```
which looks super weird so I ended up printing `{}` which looks like
```js
for (;;) {}
```
The current implementation with `JSON.stringify()` is clever but unfortunately generates incorrect JavaScript. Using `jsesc` seems like a better and safer option. https://github.com/mathiasbynens/jsesc It doesn't have any dependencies and is pretty small.
I opted for escaping all the non ascii characters, so we don't display emojis anymore. I don't think that the world is ready yet for having random unicode characters inside of source files, there still are so many parts of the toolchain that breaks with them. If we want to revert back on this decision, there's a `minimal` option on jsesc which only escapes values that need to in order to generate valid JavaScript file (assuming the encoding of the file is set to utf8).
Also, while working on React Native, we've seen that there is an optimization inside of jsc for js files that are all ascii: it doesn't do a copy for the conversion to ucs16.
Fixes#163
We were not printing the directives if the body of the function was empty in babylon. Also, we were printing way too many \n
```js
echo "function fn() { 'use strict'; }" | ./bin/prettier.js --stdin
function fn() {
"use strict";
}
```
```js
echo "function fn() { 'use strict'; }" | ./bin/prettier.js --stdin --flow-parser
function fn() {
"use strict";
}
```
DeclareInterface (flow) and InterfaceDeclaration (babylon) are the same type so should behave the same way. I am using the same `declare` trick where I only add it if you are inside of a `declare module` block.
Flow doesn't have a different ast node for `type` and `declare type`. Let's always use the heuristic to be inside of a `declare module` for both ast. This way more snapshot tests are passing between the two parsers.
This is working on the flow parser but not babylon
```js
echo 'class C<T> { submit<T>() { } }' | ./bin/prettier.js --stdin
class C<T> {
submit<T>() {}
}
```
If there you are opting in for double quote but there's a string with a double quote in it, it's better to swap to a single quote to avoid having too many `\`. Note that if there are both single and double quotes in the string, we should use the default string instead.
Fixes#139
This is working on the flow parser but not babylon
```js
echo 'function f(...flags: Array<boolean>) {}' | ./bin/prettier.js --stdin
function f(...flags: Array<boolean>) {}
```
Christopher Chedeau
