* Add eslint as dev dep, reorder scripts.
* Add tests & docs to eslintignore.
* Add eslintcache to gitignore.
* Update yarn lock file 😽.
* Add linting step in the test pipeline.
* Add a set of really basic rules for linting.
* Fix linting 🚀.
* No need for .jsx files to be linted...
* Reorder rules alphabetically.
* Refine rules: drop styling ones, only keep what provides dead code elimination.
* Add no-console rule to be consistent along with the no-debugger one.
* Remove empty line.
* Add eslint-disable-next-line no-console where console log/warn/error are allowed.
* Drop no-console rule.
* Remove eslint-disable-next-line no-console comments.
* Remove linting step in Travis CI.
* Fix linting after merging current master.
* Run `npm test -- -u` after noticing one test was out of sync.
* Drop eslint references from previous implementation.
* Revert yarn lock file.
* Revert scripts ordering.
* Fix incorrect yarn lock file.
In #1251, we now have a proper whitelist of all the types that should have parenthesis. Turns out, it included NullableTypeAnnotation which is `?a`. For `?a => void` this wasn't needed but for `(?(a => b)) => c` it was! It's better to always put it anyway if it's not just a simple literal.
I've added tests for all the combinations I could think of, so we'll catch regressions if they happen.
Fixes#1353
We've had this issue since the beginning and I tagged it as 1.0 but haven't managed to fix it by then. We shouldn't allow things to break in the argument list if we are in the last argument expansion mode. It turns out that we now have all the building blocks needed to fix this:
- have a special way to flag when we are printing the last argument expansion in the code that prints the argument list
- have a way to remove all the softlines from the argument list
Fixes#1301
This is the second part of the fix for the performance regression seen in #1250. In #1217, for correctness reasons, we're now traversing all the conditional groups. This means that we're now in O(n^2). But, in practice, many of those groups are === between each others. So we only need to recurse through one of the instances to know if it's going to break.
This makes the first example go from not terminating to being instant. The second one going from not terminating to taking ~1s. We can also make it instant by tweaking the printing phase, but that's for another PR.
The implementation was checking if the comment was inside of the expression range, which seems like a good idea. Unfortunately, the expression range is not what's inside of `${}` but the actual AST node, which incidentally doesn't include comments. So the logic was off and returned `undefined` which threw afterwards.
Another solution is to find the first quasi where start is > comment start. This means that the comment appeared between the quasi before and this one... therefore in the expression before!
The flow parser has issues with unicode where it makes node location invalid, there are likely other places where node locations are off. So instead of throwing with a weird error, let's attach it to the first one if it doesn't work.
Fixes#1293
As I was debugging #1248, I found out that the code to fix was actually making things worse. The other two branches are for decorators and deleting some random value of a function. I ran all the tests and the flow object is actually now preserving empty lines and didn't change anything else.
I'd rather remove all those and if something comes up then fix it properly upstream than having those crutches that we don't know why they exist anymore.
In #1257, I discovered that if there's a `""` doc at the end, it's not going to trim the previous one correctly. It also happens to fix a few existing things.
This one is pretty crazy. In #927, I changed
```js
concat(["(", join(concat([", "]), printed), ")"]),
```
into
```js
concat(["(", join(concat([", "]), printedLastArgExpanded), ")"]),
```
which makes the example in #1203 look ugly. The crazy thing is that `JSON.stringify(printed) === JSON.stringify(printedLastArgExpanded)`. So they are deep equal but not the same object. In a non-mutative world, this should cause any problem, but we actually mutate those to propagate breaks.
In the break propagation, we only looked at the first one in case of a conditional group. But, because the two were the same object then it also applied to the second one and happened to be the correct behavior! When I changed that piece of code to be two distinct objects, it no longer worked by accident and caused a bunch of weird issues where breaks didn't propagate correctly.
The solution for this case is to propagate the breaks on all the conditions. I'm pretty sure that this is the expected behavior, we want to deeply recurse in all of them, we don't propagate it up the boundary anyway.
The other use case for `traverseInDoc()` is `findInDoc()`, right now it searches for the first conditional group but it seems very arbitrary. I changed it to not search on any and none of the tests are failing, so I think it's safe(tm). If it triggers weird behavior, then it'll at least be expected and not randomly explode at us if we move groups around.
I tried to go through all the conditions for `findInDoc()` but it triggers a few failures (the output look bad). I'm not really sure why. https://gist.github.com/vjeux/5fb7566cc3d65974817d512d1ef6abe1Fix#1203
In #847, I used a heuristic to find if the element was going to be expanded. But, it wasn't 100% accurate because we couldn't know in which conditionalGroup we would land. We added a way for the parent to tell that function if we should be in `expandLastArg`. By replacing the condition by this variable, it now fixes the issues!
This is so good that adding the right abstraction fixes problems across the board :)
Fixes#997
It turns out that we can't reliably detect with the ast if a comment is before or after the ). In order to fix this same problem with `if` I added the `getNextNonSpaceNonCommentCharacter` function. We can use the same here to fix the problem.
Fixes#933
Brian Ng