react-codemod

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago. When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts. There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: https://github.com/reactjs/react-codemod. We also call attention to the automated migration scripts in all major releas

We are trying to strike a balance between supporting huge legacy apps that cannot be rewritten- (something Facebook has a lot of)- and encouraging safe/bug-free coding practices for future apps. In this case, we felt the right balance was to preserve legacy functionality while using a name that would hopefully discourage new usage (so as to avoid the potential pitfalls inherent in the legacy API). And we provided a codemod to help with the "huge legacy apps": https://github.com/reactjs/react-codemod#rename-unsafe-lifec... We've run it internally already to update ~14,000 components.

One of the main focuses of 16.3 is to enable open source libraries to update their code in advance of deprecation warnings. (We're trying to go one step beyond SEMVER- so that application developers don't have to be bothered by warnings in third party code that they can't change.) And the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifec... We've used it internally (at Facebook) to update ~14,000 components already, so it's well tested.

Just chiming in to note that the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifec... We used it internally (at Facebook) several weeks ago to update ~14,000 components that used the unsafe lifecycles.

Check out react-codemod [0] for practical React / JavaScript examples. To give an example with explanation, in the v15.5.0 release they deprecated React.createClass [1] in favor of regular ES2015 classes, with a fallback to a module. [0] https://github.com/reactjs/react-codemod [1] https://reactjs.org/blog/2017/04/07/react-v15.5.0.html#migra...

I totally agree. I'd love to see more languages supporting bidirectional code transforms. I've used jscodeshift [0] to refactor large JavaScript codebases, and it's absolutely amazing. It's incredibly empowering to write code to update your code. For example: unhappy with your test assertions library? Safely migrate all your tests with a quick script. The React team has a react-codemod [1] repo which has scripts to help you update to newer APIs. That means they can make changes and iterate on improvements without leaving people behind. Quite frankly, I don't see why more tools, libraries, and frameworks wouldn't do the same. [0] https://github.com/facebook/jscodeshift [1] https://github.com/reactjs/react-codemod

For example, the React team provide a set of codemods to help automatically upgrade codebases when there is a new version of React (https://github.com/reactjs/react-codemod). Until `recast` gets TypeScript support, everybody who uses TypeScript has to do this repetitive work manually. Another example is how many `css-in-js` libraries require Babel plugins to work their best (e.g. https://github.com/emotion-js/emotion/tree/master/packages/b...). And additionally there are also plugins that optimize React code (e.g. https://github.com/thejameskyle/babel-react-optimize).