Babylon has a bug (I guess) with locations for classes where decorators are involved. Instead of the class starting at the first decorator, it starts at the beginning of the `class` keyword. By moving the location to the first comment, it solves --some-- of the issues with decorator comments.
The issue is really that the media query parser fails to parse the inner queries and just gives a raw string for the expression, but it should be safe to remove extra spaces. I can't make it rmeove spaces inside () that way unfortunately :(
If you put a space, `{loose: true}` is going to parse them as word + paren instead of func. It doesn't impact correctness and i'm not really sure how to clean the ast, so let's just make the test pass. I haven't seen this anywhere in real code.
It's very annoying to have to have a static definition of the ast, we should instead just traverse the objects to discover it. We just need to make sure not to have any cycles, but it's also good for debugging anyway.
This fixed a few comments already :)
- I want to get to a place where we don't use ast-types in order to do the traversal. This almost removes it from fast-path.
- Remove FastPath.from and copy
- Use .prototype instead of the weird Fpp
- Remove unused TODO
- Remove unused needsParen condition with a bunch of associated code
A long time ago I introduced the ability to break for import statements. Then, later on, we removed the ability for require to break and go over the 80 column mark. In order to be consistent, we should do the same for import statements as well.
There can often be something that breaks inside of `extends` so it's looking weird to break twice. It now only breaks on `implements` and make sure to put each element on its own line.
Fixes#1520
I didn't intend for putting parenthesis there in the first place but it slept through. Since it was going to trigger a ton of changes I held up changing it, but I feel like we need to do it sooner than later otherwise we're not going to be able to do it. A lot of people writing functional components are going to be very happy about this change :)
TypeScript doesn't have the concept of `?` for nullable options and instead you have to write `| null` and `| void`. This is annoying to have it use the long form, so we're now inlining them.
While working on this, I found out a few issues with the way we deal with those:
- We only align objects if the parent is a union. This means that if you have `Array<{ object }>`, the object is not aligned properly. The fix is to move the alignment logic to the union, and not the child.
- When doing so, it messes up with the comment alignment, so we have to manually handle children comment printing in the union code.
It doesn't yet fix#1727 because the hardcoded type names are different, i'll follow up in a PR.