* Add typescript as a valid parser value
Now that typescript development has started, each contributor has been adding this as a supported flag themselves.
This just adds it as an allowed option, with a warning that support for this parser is experimental.
I also tried to structure this a bit future proof, in case other experimental parsers come along.
* Simplifies the code at vjeux's request
Rather than a notion of "experimental" parsers, we'll just leave typescript out of the documentation until it's supported.
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.
In #1250, @jeresig reported that adding // prettier-ignore on a file that has a ton of conditional group still took 1.7s. The issue is that we're printing before checking for the comment. Swaping the two had the unfortunate side effect of not marking the comments as being printed, so I had to skip that safety check if there's a prettier-ignore.
With this change, adding prettier-ignore makes the file be printed instantly!
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.
Christopher Chedeau