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.
While trying to figure out how to handle both MemberExpression comments and IfStatement comments, I ended up doing this one as well... Sorry @yamafaktory :(
The logic is a bit annoying but works.
Fixes#487
There are currently three issues related to suboptimal rendering of MemberExpression chains. The previous implementation was trying to flatten only a single group at the same time, but it didn't work well because we didn't have the full context to be able to make decisions.
In this implementation, I'm going through the entire chain at the same time and group it into logical units and make decisions based on this. It solves all the problems I can think of and if we need to tweak it in the future, it should be easy.
Fixes#268Fixes#212Fixes#21
If there's a break inside of a call, we want to force it in the group, otherwise it may get the indentation wrong. See the real-world use case in #513Fixes#513
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
* [Failing test] Comments in call expression
```js
foo(
// Hi
)
```
prints
```js
foo
// Hi();
```
* add one more failing case
* Don't group last args that has comments attached
* Update snapshot
It turns out that the range is not inclusive. It incorrectly included a \n after and would expand way more objects than we intended to.
I found it while running prettier on the codebase.
I'll make 0.14.1 for this.
* Print numbers in a uniform way
- Still preserve the radix (binary, octal, hexadecimal or decimal) used
in the original source code.
- Still preserve scientific notation.
- Add 0 to fractions. `.1` -> `0.1`
- Remove trailing dots from integers. `1.` -> `1`
- Always print the radix letters lowercase. `0b`, `0o`, `0x`
- Always print scientific notation lowercase. `1e1`
- Always print hexadecimal digits uppercase. `0x123ABCDEF`
- Remove unneeded plus in scientific notation. `1e+1` -> `1e1`
- Remove unneeded zeroes in scientific notation. `1e-001` -> `1e-1`
- Preserve leading zeroes in non-decimal radix. This can be useful when
working in binary, and having both `0b111000` and `0b000111` for
example.
* Always print numbers lowercase
* Remove trailing dot in scientific notation
* Update snapshots
Another attempt at solving the issue where objects are not expanded the way people expect. If there's any new line in the original source, it's going to expand it. This gives more control to the user in how the objects should be formatted.
Fixes#74
It turns out that in an unlikely turn of event, the inner group can be inline and not print the opening paren but the outer group breaks and outputs the closing paren which generates invalid JavaScript.
I tried removing the group altogether and no tests failed, so I'm assuming the group wasn't needed in the first place. If it was, we should add tests to cover this.
Fixes#501
When reading the Readme file I noticed that the first `foo` method has only 3 args but every other `foo` method has 4. Therefore, I am adding a 4th arg to the first `foo` method for consistency.
* Proper support for dangling comments
In one code path, the dangling comment case is not properly handled. So I added the dangling comment, but it turns out that we only print manually in two node types: Program and BlockStatement. I made the generic printComment function print it everywhere but those two nodes. I tried to get rid of those special cases but unfortunately we need them there otherwise they are not printed at the right place.
Fixes#20
* Output dangling comments in specific places
The logic was already working, it was just special-cased to the first comment of the file! Presumably because the new line detection logic used to be broken ;)
I manually checked the first 10 snapshots and they are all legit, so I assume that all of them are.
Fixes#356
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
Christopher Chedeau