tl;dr: If you need to use both Babel-generated and TypeScript-generated files together, make sure both the Babel and Typescript transpilers are targeting the same ES/module technology.
Currently, I’m working on a legacy Angular 1 project that’s using TypeScript (TS). The codebase has grown massively, and given Angular 1’s performance issues with complex client apps, the team has decided to look into other alternatives. One of the alternatives is React.js.
Side note: Part of the challenge we’re facing is ensuring production up-time and ongoing new feature development. This pretty much eliminates the option of a complete overwrite. We need to ensure backwards compatibility with existing code in any kind of re-engineering effort we take. One of the options we thought of is “componentizing” central parts of the app, which we could pull out of the main project into a separate solution that can be rewritten with better patterns and better overall performance. Given that React has a better data-binding mechanism than Angular 1, we expect a re-write of these central components in React would make for considerable performance improvements in the app. Moreover, this abstraction of common logic would improve readability, reusability and maintainability on the main app.
Since the main app uses TS, we needed these transpiled React components to be compatible with the TS code. But … how?
The answer is in fact pretty simple: Make both the TS and the Babel transpilers produce the same artifact tech. Let me elaborate …
In our case, our TS transpiler was configured to generate ES5, AMD files. So we needed our Babel transpiler to also produce ES5, AMD files. Then, we could easily import Babel-generated files into our TS-generated ones. Babel out-of-the-box generates ES5 files, so all we needed was to take those and transform them into AMD files. It turns out, there’s already a plugin for that.
Empowered with that plugin, we’re now able to write React components in ES6, and have them be used by our TS code within our app.