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.
We require single quotes in our eslint config, which conflicts with prettier's default rules. Now the `prettier-args` custom variable allows anyone to set the arguments passed to the prettier command when it runs.
Might be nice to eventually build this up out of individual customization options (ie. `(setq prettier-single-quote t)`), but this is a pretty simple approach that works for now.
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!)
Christopher Chedeau
