3 ms·

Hi Alex (I have an email from you that I have to respond to)! TS guy here. We've had discussions around this and the reason we use our own AST format is for com

Hi Alex (I have an email from you that I have to respond to)! TS guy here. We've had discussions around this and the reason we use our own AST format is for compilation speed and editing scenarios, both of which our team really focuses on. I'll also note that incredible folks like James Henry have already written tools to convert TypeScript ASTs to the ESTree format[1]. I've heard it's been working well for using ESLint on TypeScript code. [1]: https://github.com/eslint/typescript-eslint-parser https://github.com/eslint/typescript-eslint-parser

rattray 9y ago
Hey Dan! Yeah, prettier has also been working hard[0] towards TS support, frequently referencing typescript-eslint-parser (I haven't been involved). Personally I want to go the other way – ESTree to TS – so while the prior art is helpful, very little of the code could be reused. If TypeScript (or a fork thereof) exposed an option to use your own parser, an ESTree -> "TSTree" library could be used to map the output of any babel plugin to TypeScript. I'm sure you've discussed/considered this; presumably speed is a top concern. [0] https://github.com/prettier/prettier/issues/13 https://github.com/prettier/prettier/issues/13 and https://github.com/prettier/prettier/issues/1306 https://github.com/prettier/prettier/issues/1306