- 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.
This PR adds two things:
`--debug-print-doc` command that prints the formatted doc
```js
echo "<div><</div>" | ./bin/prettier.js --stdin --debug-print-doc
[
groupConditional(
group([
group([ "<", "div", group([ indent(2, []), softline() ]), ">" ]),
"<",
"</",
"div",
">"
]),
[
group([
group([ "<", "div", group([ indent(2, []), softline() ]), ">" ]),
"<",
"</",
"div",
">"
]),
group([
group([ "<", "div", group([ indent(2, []), softline() ]), ">" ]),
indent(2, groupBreak([ hardline(), "<" ])),
hardline(),
"</",
"div",
">"
])
]
),
";",
hardline()
];
```
The ability to view the IR in real time on the browser display:
The way it works is pretty cool, we take the doc IR and print a valid JavaScript string out of it, that we then send to prettier in order to make it look good :)
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.
Extracted out parse and attachComments. Moved the options normalization in the exported function.
This way, we have a super clean format function :)
```js
function format(text, opts) {
const ast = parse(text, opts);
attachComments(text, ast, opts)
const doc = printAstToDoc(ast, opts)
const str = printDocToString(doc, opts.printWidth)
return str;
}
```
Make all the files have a single module.exports call at the end of the file.
I added a missing `"use strict";` and removed a few unused functions from utils at the same time.
- 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...
It doesn't compile cleanly anymore:
- esutils checks for Buffer.isBuffer without ensuring that Buffer exists.
- for version, we require a json file, need a rollup extension for that.
I no longer hardcode the version number.
Note: we need to merge this pull request after we have done the release so that the version number is correct and need to rebuild the minified version in a subsequent commit.
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`.
* Remove +1 from newline detection
All the changes are related to spurious `;`. Sometimes the logic is more correct, sometimes less. Since `;` are going to be removed after the first save, I don't think it matters that much.
* Handle inconsistent `end` node locations when looking for newlines
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
The Nuclide codebase uses features that are still proposals which require a flag to be enabled. Babylon parses them fine without any flags.
Let's enable them by default as it doesn't cost much, you either are using those features and you don't want the parser to break, or you are not and you don't care.
After this and #218, none of the nuclide files are throwing exceptions! (yay!)
There's a handful of files inside of Nuclide that throw exceptions because an assertion is raised.
```
{ AssertionError: ']' === '`'
at fixTemplateLiteral (/Users/vjeux/random/prettier/src/util.js:105:10)
at Object.util.fixFaultyLocations (/Users/vjeux/random/prettier/src/util.js:45:5)
at getSortedChildNodes (/Users/vjeux/random/prettier/src/comments.js:25:8)
at getSortedChildNodes (/Users/vjeux/random/prettier/src/comments.js:61:5)
at decorateComment (/Users/vjeux/random/prettier/src/comments.js:71:20)
at decorateComment (/Users/vjeux/random/prettier/src/comments.js:85:7)
at decorateComment (/Users/vjeux/random/prettier/src/comments.js:85:7)
at decorateComment (/Users/vjeux/random/prettier/src/comments.js:85:7)
at decorateComment (/Users/vjeux/random/prettier/src/comments.js:85:7)
at /Users/vjeux/random/prettier/src/comments.js:129:5
```
When trying https://github.com/facebook/nuclide/blob/master/pkg/nuclide-task-runner/lib/main.js#L174
It throws in the fixTemplateLiteral method.
That method was added to fix https://github.com/benjamn/recast/issues/216 more than a year ago
```js
var x = {
y: () => Relay.QL`
query {
${foo},
field,
}
`
};
```
I've checked (and added a test) and it now parses and prints correctly without that method. So it should be safe to remove.
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";
}
```
Babylon has a bug where it doesn't escape DirectiveLiteral properly. Except for `'use strict';`, this never happens in real world code, so let's put strings in a array in order to workaround this bug and have the same output on both parsers.
https://github.com/babel/babylon/issues/289
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.
The search for an empty line incorrectly does +1 which happens to be skipping a `\n`, but in case of windows line endings it skips the `\r` but sees a `\n` afterwards and incorrectly assumes that it is a empty line.
This doesn't change the behavior of doing +1 when there's not a line ending. Making it correct actually triggers a bunch of changes, where half of them are better and half of them regressions. So I'm going to send another pull request to fix that case.
Another issue where babylon and flow ast are different. In babylon, it is NumericLiteral but flow is Literal. All the tests are running on flow so were working correctly, but the default in the command line is to use babylon, so people report bugs with it.
When looking into adding a test, I realized that the logic was inside of bin/prettier.js and therefore only applying to the cli. Moving it to index.js and adding a test so that it's more robust :)
Christopher Chedeau
