As I’m reading through answers from my tweet ( https://twitter.com/Vjeux/status/859444410869727232 ), a lot of people are eagerly waiting for TypeScript support to push it through their codebase at work. You are working on something really impactful!

Guys, I just wanted to let you know that I highly appreciate that you’re building support for TypeScript in prettier! Looking forward to start using it across all my projects 👍

I started integrating eslint-parser-typescript’s master branch and fixing what it breaks, just so you know.

this is something im interested too. I can work on few as well

If you are interested, how master looks on inferno, pretty damn close 😃 https://github.com/infernojs/inferno/pull/1069

Here is a list of unique errors that still happen:

• Error: Comment “*param help” was not printed. Please report this error!
• Error: Comment “*type” was not printed. Please report this error!
• Error: Comment “closing comment” was not printed. Please report this error!
• Error: Comment “error – declarations must be adjacent” was not printed. Please report this error!
• Error: Comment “error” was not printed. Please report this error!
• Error: Comment “error, not same type” was not printed. Please report this error!
• Error: Comment “inherits bar. But BB is abstract, so this is OK.” was not printed. Please report this error!
• Error: Comment location overlaps with node location
• Error: Value undefined is not a valid document (https://github.com/eslint/typescript-eslint-parser/pull/251)
• Error: did not recognize object of type “TSParameterProperty” (#1507)
• Error: did not recognize object of type “TSTypeParameter” (#1508)
• Error: unknown type: “TSAbstractKeyword” (#1505)
• Error: unknown type: “TSConstKeyword” (#1502)
• TypeError: Cannot read property ‘expression’ of undefined ( https://github.com/eslint/typescript-eslint-parser/issues/249 )
• TypeError: Cannot read property ‘replace’ of undefined (#1503)
• TypeError: Cannot read property ‘type’ of null (#1506)
• TypeError: Cannot read property ‘type’ of undefined (#1509 & https://github.com/eslint/typescript-eslint-parser/issues/250)

And here is the whole output (careful big file).

So we’re exceptionally close to not crashing on any valid TypeScript 😄.

Whoever wants to try to fix any error, drop a line. I’ll start with TSConstKeyword. Happy hacking!

After #1483, down to

• 526: prettier(input) !== prettier(prettier(input))
• 502: ast(input) !== ast(prettier(input))
• 52: Error: unknown type: xxx
• 60: Error: did not recognize object of type xxx
• 78: TypeError: Cannot read property ‘type’ of undefined

So, this divided the number of broken tests by 2!! Keep it up 😃

I should be able to help out with some on Thursday too, as I have the day off 😄

@azz, none of those are syntactically valid JS, so I wouldn’t worry too much about it.

Just FYI to all you wonderful people working on TS support in prettier, we have merged in some major PRs to typescript-eslint-parser (which powers the prettier TS parser) today.

Of particular note:

1. The typescript-eslint-parser codebase itself has been refactored (https://github.com/eslint/typescript-eslint-parser/pull/261), and whilst this does not change any ASTs, it will affect any of you that have forks of the project.

2. @Pajn’s PR to normalize type parameters (https://github.com/eslint/typescript-eslint-parser/pull/196), this is a breaking change for relevant ASTs and so will affect (hopefully greatly improve) relevant prettier work.

There is a chance @Pajn has some relevant prettier WIP, but I know that he has been busy moving cities, so not sure of the status.

I also added printer for TSHeritageClause and TSExpressionWithTypeArguments.

I’m taking a look at TSExportKeyword at the moment.

All keywords are done. Looking at TSNamespaceFunctionDeclaration.

TSDecorator is still up for grabs.

TODO:

• questionToken is not printed:

  - [Symbol.iterator]: { x };
  + [Symbol.iterator]?: { x };
  

• readonlyToken is not printed in mapped types:

  -var v03: { readonly [P in keyof T]: T[P] };
  +var v03: { [P in keyof T]: T[P] };
  

• Do not put [] around Literal nodes on LHS in interface.

  interface I {
  -    [Symbol.iterator]: number;
  -    [s: symbol]: string;
  -    "__@iterator": string;
  +  [Symbol.iterator]: number,
  +  [s: symbol]: string,
  +  ["__@iterator"]: string
  }
  

• Print parens around arrow functions in this case:

  -var x = (v => v) as (x: number) => string;
  +var x = v => v as (x: number) => string;
  

• Extraneous newline on second print. Also occurs with functions:

     export var m2_a1: number;
  
  +
     export class m2_c1 {
       m2_c1_p1: number;
  

• Unstable re-print:

  class C5 {
    async f() {
  -    const x = yield* (async function*() {
  -      yield 1;
  -    })();
  +    const x =
  +      yield *
  +      (async function*() {
  +        yield 1;
  +      })();
    }
  }
  

instanceof fix merged, thanks for that! Literally no idea why I didn’t PR that working branch before 😄

Worth noting that typescript-eslint-parser had a breaking change recently, which will presumably need fixing here.

Thanks, @despairblue!

We are trying to get in as many necessary breaking changes as possible before we declare prettier TS support “stable”.

Another tiny one (in terms of the changes required in prettier) coming: https://github.com/eslint/typescript-eslint-parser/pull/219

We will need to change the parser config to use comment: true, rather attachComment: true as it currently is.

Just FYI I am waiting to hear back from @Pajn on https://github.com/eslint/typescript-eslint-parser/pull/196

I am assuming that is currently blocking a related prettier PR, although one is not mentioned specifically

I just opened https://github.com/eslint/typescript-eslint-parser/issues/250 on typescript-eslint-parser for decorators being inconsistently outputted and #1509 as a workaround on prettier, but I’d rather not ship it and get it fixed upstream.