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
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.
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.
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.
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 :)
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
Christopher Chedeau
