3 ms·
I hope so – so far it looks a lot less powerful. One aspect that's disappointing to me is that the AST they use seems fairly idiosyncratic; Babel's is quite cl
by rattray 10y ago
I hope so – so far it looks a lot less powerful.
One aspect that's disappointing to me is that the AST they use seems fairly idiosyncratic; Babel's is quite close to the ESTree spec, and even easier to work with.
Relatedly, it also doesn't look possible to swap out the parser, which Babel makes easy. I'd love to use the TS typechecker for a compile-to-js lang I'm working on ([0]), but would need to use my own parser.
[0] http://lightscript.org http://lightscript.org
- DanRosenwasser 10y agoHi 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 10y agoHey 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