{"action":"opened","issue":{"url":"https://api.github.com/repos/kentcdodds/babel-plugin-macros/issues/94","repository_url":"https://api.github.com/repos/kentcdodds/babel-plugin-macros","labels_url":"https://api.github.com/repos/kentcdodds/babel-plugin-macros/issues/94/labels{/name}","comments_url":"https://api.github.com/repos/kentcdodds/babel-plugin-macros/issues/94/comments","events_url":"https://api.github.com/repos/kentcdodds/babel-plugin-macros/issues/94/events","html_url":"https://github.com/kentcdodds/babel-plugin-macros/issues/94","id":389023504,"node_id":"MDU6SXNzdWUzODkwMjM1MDQ=","number":94,"title":"Let's discuss TypeScript support.","user":{"login":"FredyC","id":1096340,"node_id":"MDQ6VXNlcjEwOTYzNDA=","avatar_url":"https://avatars0.githubusercontent.com/u/1096340?v=4","gravatar_id":"","url":"https://api.github.com/users/FredyC","html_url":"https://github.com/FredyC","followers_url":"https://api.github.com/users/FredyC/followers","following_url":"https://api.github.com/users/FredyC/following{/other_user}","gists_url":"https://api.github.com/users/FredyC/gists{/gist_id}","starred_url":"https://api.github.com/users/FredyC/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/FredyC/subscriptions","organizations_url":"https://api.github.com/users/FredyC/orgs","repos_url":"https://api.github.com/users/FredyC/repos","events_url":"https://api.github.com/users/FredyC/events{/privacy}","received_events_url":"https://api.github.com/users/FredyC/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-12-09T13:30:37Z","updated_at":"2018-12-09T13:30:37Z","closed_at":null,"author_association":"NONE","body":"I am well aware that this is Babel world project and it was meant like that from the start. However, I would like to initiate the discussion here what it would take to have macros available in TypeScript world. Macros are such a great concept it would be almost a crime to leave it like this.\r\n\r\n## Problem\r\n\r\nI am mostly coming from the situation I am trying to solve now. The [LinguiJS](https://lingui.js.org/) is going to be [using macros](https://lingui.js.org/rfc/001_macros_message_descriptors.html) to transform i18n elements. While in a Webpack world it's possible to run `ts-loader` and `babel-loader` in tandem, it already introduces challenges, eg. keep JSX untransformed so Babel can have enough information and do JSX transformation on its own later along with Macros.\r\n\r\nAlso, other toolings needs to solve the same. Be it extraction process of Lingui itself or [Jest testing](https://github.com/lingui/js-lingui/issues/407) or any other bundle I suppose. None can use Webpack loaders and have its own way around. This is no good for a whole ecosystem in my opinion.\r\n\r\nI am sure this situation is not unique and with [rising adoption of TypeScript](https://2018.stateofjs.com/javascript-flavors/typescript/) there will surely be more projects popping out trying to solve the same. I feel it would be rather unhealthy to keep ecosystem separated like this. Not only for library authors, but for users as well.\r\n\r\n## Solutions?\r\n\r\nTypeScript has it's own \"plugin\" system or rather it's called [custom transforms](https://dev.doctorevidence.com/how-to-write-a-typescript-transform-plugin-fc5308fdd943). There is some AST [apparently](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#traversing-the-ast-with-a-little-linter), but I do have trouble finding a real documentation for that. Honestly, I've never been fiddling with AST in Babel, so I am probably the least capable person to deliver any valid information in here.\r\n\r\nWould it be viable to basically have a Typescript transform that can understand babel macros out of the box? Most likely that due to AST difference the authors of macros would need to account for both variants, but on the user end it would mean complete transparency as you could use either language without hassle.\r\n\r\n---\r\n\r\nOne might argue that since there is [TypeScript support in Babel now](https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/), it's a clear path and no need to bother with this. I would agree in case that support would be building on a real TypeScript compiler. Since it's completely separate implementation, it might introduce unexpected errors and incompatibilities. VSCode checking can tell A and then Babel will transform it into B. Current lack of some features is an example of that and more might come. Personally, I think it's wrong path, but that's not the point of this discussion. Perhaps I am mistaken on this I would love to be proven otherwise. \r\n\r\ncc @tricoder42 "}}
{"actor":{"display_login":"FredyC"}}