* Add handleAssignmentPatternComments helper function.
* Add new tests 🎉.
* Remove unecessary arg in function.
* Reorder it.
* Experimental fix for key comments in the printComments function.
* Pull master and switch to @vjeux implementation.
* Fix bad rebase.
* Add additional checking for enclosingNode in handleObjectProperty function.
There is an off by one error which made the algorithm not work all the time. In many cases, it actually is the opposite, so whenever you save, it adds/removes that line. I noticed it during the --debug-check run on our codebase but didn't investigate.
Fixes#723
* Extend ReturnStatement case to better handle comments in argument 🎉.
* Update test.
* Add missing space between return and left parenthese.
* Fix current tests and add new tests.
* Do not break one-liner returns.
* Revert specific test.
* Patch from #683.
In #563 it looked odd that there was no space before `//`, it turns out that we don't automatically go to the new line for dangling comments. I think that we just should no matter what, so this is what this diff does.
Fixes#563
When there is a comment right before the first `.`, we want to force break such that the comment is printed on its own line.
Note: this needs to be based on-top of #667 as it always indent the first `.`
Fixes#613
* Add prettier indentation for UnionTypeAnnotation in ObjectTypeAnnotation.
* Update tests accordingly.
* Fix indentation.
* Update a bunch of tests 🚀.
* Switch to a more consistent indentation.
* Fix tests to match new indentation 🚀.
We want to preserve an empty line before the last comment. It is added as a trailing comment of the node and adding the same logic to detect if the next line is empty is working.
Fixes#566
If you removed it before #561, it would trigger an exception in the globalPreceding branch. But now that we don't have this hack anymore, it works fine.
Fixes#543
Babylon has a two top level nodes: File and Program whereas flow just has Program. This causes two things two happen that prevents comments from being displayed:
1) Because there's a single node, none of following/preceding/enclosing exist. We ran into a TOOD case that we now need to fill. We just need to attach comments to the only node we have: the ast.
2) Both the raw comments and the computed comments are set on the `.comments` field of the object, however, it is being reset after calling `attach`, so we lose the computed comments :( The fix is to use a local variable and delete the comments before calling `attach`.
The original motivation for this change is trying to fix#560 where the comment was attached to the JSXText node instead of the JSXExpressionContainer because it used the globalPrecedingNode. In general, I don't think that it is very safe to attach a comment to a random node just because it happened to be before.
I tried to delete the globalPrecedingNode codepath and I think that it actually improves the results. I'll add inline comments in the pull request to explain the various changes.
Fixes#560
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
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
* [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
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
* 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
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
The original intent of it was for `if then else` and `try catch` as they aren't likely to be empty, but it accidentally caught function bodys, which have many valid reasons to be empty. Let's special case those out.
Rogelio Guzman