4 ms·

I wonder if the plugin system will evolve into an AST-transform ecosystem like Babel's.

DanRosenwasser 10y ago
There's already a way to consume TypeScript through its API and inject a custom transform today, so a lot of the machinery is already in place.
Touche 10y ago
I hope not. Didn't we already learn this lesson from macros? Having code that appears to do one thing but actually does something very different is a maintenance nightmare. Once the people who decided to add that AST transform plugin are gone and new people take over that don't know about it, the trouble really starts. Again, we've seen this in languages with macros. At least with macros it's part of main codebase; you usually have to include them in some way. With these AST transform systems the secret is tucked away in a build script somewhere.
- bpicolo 10y ago
  I've had poor experiences with PostCSS w/ regards to AST transforms. The different plugins tend to not interact with each other at all because they're just transforms. Feels worse than something that works together all around like scss.
- 15155 10y ago
  Much of this, IMO, is due to a lack of a type system. The maintenance nightmare comes from when behavior changes and you have no way of knowing about it - a type system staves off some of this.
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 ago
  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 10y 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

There's already a way to consume TypeScript through its API and inject a custom transform today, so a lot of the machinery is already in place.

Touche 10y ago

I hope not. Didn't we already learn this lesson from macros? Having code that appears to do one thing but actually does something very different is a maintenance nightmare. Once the people who decided to add that AST transform plugin are gone and new people take over that don't know about it, the trouble really starts. Again, we've seen this in languages with macros. At least with macros it's part of main codebase; you usually have to include them in some way. With these AST transform systems the secret is tucked away in a build script somewhere.

bpicolo 10y ago
I've had poor experiences with PostCSS w/ regards to AST transforms. The different plugins tend to not interact with each other at all because they're just transforms. Feels worse than something that works together all around like scss.
15155 10y ago
Much of this, IMO, is due to a lack of a type system. The maintenance nightmare comes from when behavior changes and you have no way of knowing about it - a type system staves off some of this.

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 ago
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 10y 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