I implemented indenting based on any character that's before the `${` but it was not the right behavior. Instead people want to indent based on the indentation of this line. It's easy to fix :)
Fixes parts of #1626
In 1.3.0, we shipped a change that makes template literal always inlined as single arguments of a function. The problem with template literals is that they whitespace is significant so we can't change it. There are two cases:
```js
call(`
template
template
`);
```
and
```js
call(
`template
template`
);
```
If you always make the same decision to inline, you're going to be wrong for the other use case. The solution that I found that works is to figure out if there's a `\n` before the backtick `` ` ``. If that's the case, then don't inline, otherwise do. We're trying to avoid looking at the source as much as possible but this is one example where we actually don't have a choice if we want to keep the output sane.
1.3.0 made the jest codebase significantly worse because of this. The issue is that once things have been moved, this heuristic won't be able to undo it. So people need to have this fix applied before they run 1.3.0, otherwise it's going to damage their codebase unless they manually change everything back, which is a pain. So I'm going to land this as a hotfix in 1.3.1.
Fixes#1492
* 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.
This has come up many times in the past and while going through the fb codebase, there are a few instances where we group array elements logically using empty lines and it's a shame that they are gone.
This reverts commit 7148184d65.
There are four types of literals where escapes were normalized:
1. Strings ('\xAb' and "\xAb")
2. Regexes (/\xAb/)
3. Untagged template literals (`\xAb`)
4. Tagged template literals (tag`\xAb`)
However, changing the case of the escapes alters the runtime behavior of
in two of the above cases.
```js
/\xAb/.source === '\\xAb' // true
String.raw`\xAb` === '\\xAb' // true
```
So for regexes and tagged template literals the escapes must not be
changed. Instead of enforcing lowercase escapes in only 50% of the
different cases, it was decided not to bother with escapes at all.
Closes#562.
It turns that our hasNextLine logic needs to be tuned to skip all the trailing comments. The code is not pretty but it does the job. It looks like it fixes a bunch of things in the test cases :)
I made sure that nested inline comments are NOT valid JavaScript
```js
/* /* a */ */
Uncaught SyntaxError: Unexpected token *
```
so it is okay to do a dumb search for */ when you are in a comment
* Print \x and \u escapes in strings and regexes lowercase
Theoretically, we would want to do this for escapes int identifiers as
well. However, neither flow nor babylon preserves escapes in
identifiers. For example, `\u0061.\u{0061}` cannot be distinguished from
`a.a`. Nobody uses such escapes in real code anyway. It could also be
considered a feature that such escapes are converted to real unicode
characters.
* Update snapshots
* Normalize escapes in template literals
* Update snapshots
* 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.
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.
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
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
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 brings in the flow test suite that contains a ton of JavaScript parsing edge cases
- This creates snapshot tests using the pretty printer for all of them
- If uncomment `RUN_AST_TESTS` line in `tests/run_specs.js`, it checks ast(pretty_print(x)) == ast(x). Right now, "178 failed, 197 passed, 375 of 377 total". So half of the tests are not passing, most of them are crashes and many of the rest are subtle issues.
Lucas Duailibe