* fix(typescript): fix module block, add enum initializers and fix type parameters
* fix(typescript): use printStatementSequence for TSModuleBlock
* fix(type-params): move typeParameters out of printFunctionParams
* refactor(type-params): move typeParameters out of printArgumentList
I have no idea if it's even valid but it threw on 8 typescript tests, now it doesn't.
```js
TypeError: Cannot read property 'type' of null
at printMemberLookup (prettier/src/printer.js:3062:16)
```
In 1.3.0, we shipped a change that makes template literal always inlined as single arguments of a function. The problem with template literals is that they whitespace is significant so we can't change it. There are two cases:
```js
call(`
template
template
`);
```
and
```js
call(
`template
template`
);
```
If you always make the same decision to inline, you're going to be wrong for the other use case. The solution that I found that works is to figure out if there's a `\n` before the backtick `` ` ``. If that's the case, then don't inline, otherwise do. We're trying to avoid looking at the source as much as possible but this is one example where we actually don't have a choice if we want to keep the output sane.
1.3.0 made the jest codebase significantly worse because of this. The issue is that once things have been moved, this heuristic won't be able to undo it. So people need to have this fix applied before they run 1.3.0, otherwise it's going to damage their codebase unless they manually change everything back, which is a pain. So I'm going to land this as a hotfix in 1.3.1.
Fixes#1492
* Make slice simpler.
* Drop htmlEscapeInsideAngleBracket function.
Use child.extra.raw (Babylon) and child.raw (Flow) to get the value instead.
* Remove unused htmlEscapeInsideAngleBracket function.
* Update test cases accordingly.
* Fix merge conflict.
* Update tests via `npm test -- -u`.
* Fix multiple consecutive spaces preservation in printJSXChildren.
* Update tests accordingly.
* fix(typescript): fix handling of new keyword
* fix(typescript): fix handling of call signatures
* feat(typescript): share type parameter formatting with flow
* feat(typescript): #1480: implement *Keyword, namespace function and class heritage
* feat(typescript): add type params and modifiers to interfaces
* chore(style): add squigly wings to if/else blocks
* fix(typescript): remove hardline before declare
We never want to break on those at it looks very weird. The reason why I didn't add this yet is because whenever it triggered in the past, the root cause was something else and it helped identify things to fix. But now the remaining ones I'm seeing are no longer underlying issues and they're just about this breaking unnecessarily, so we should just fix it.
This was added in order to follow some eslint rule but it's only confusing when it doesn't break, when it breaks the indentation makes it clear what is happening and you don't need parenthesis.
Fixes#1379
All of the discussions around ternaries are for the form
```js
cond1 ? elem1_if : cond2 ? elem2_if : elem_else
```
but some of them are for the form
```js
cond1 ? cond2 ? elem2_if : elem2_else : elem1_else
```
which is more rare and would be good to call out by adding parenthesis.
```js
cond1 ? (cond2 ? elem2_if : elem2_else) : elem1_else
```
Note that we only want parenthesis if it's written inline, otherwise the indentation is good enough to understand the flow:
```js
cond1
? cond2 ? elem2_if : elem2_else
: elem1_else
```
Right now, expressions inside of template literals are have the level of indentation of the start of the template literal. But oftentimes, expressions are nested inside of template literals and therefore the expression should have this level of nesting.
The heuristic i'm using to decide when to use the template literal nesting is if it's not the first line and if there isn't another expression before on the same line.
Christopher Chedeau