ts-migrate VS jscodeshift

Update tsconfig. Replace the content of tsconfig.json with the values from tsconfig.base.json.

Airbnb converted many millions of lines gradually using automation and wrote about it:

https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-...

And also open sourced the tooling:

https://github.com/airbnb/ts-migrate

Are you migrating with ts-migrate?

When you migrate your entire project over to TypeScript, errors like "undefined is not a function", syntax errors, or reference errors should no longer exist in your codebase. Thankfully, this is not as daunting as it sounds. Migrating your entire Node.js application to TypeScript can be done incrementally so that you can start reaping the rewards immediately in crucial parts of the codebase. You can also adopt a tool like ts-migrate if you intend to perform the migration in one go.

Flow to ts — helps to produce raw migration from Flow to TS files and reduces monkey job. TS migrate — helps convert JS files to Typescript files. A great introduction can be found here.

💡 I typed it using ts-migrate ts-migrate is a tool I strongly recommend. It's been developed by Airbnb to help to migrate easily JavaScript projects to TypeScript.

When you decide to migrate, I recommend checking https://github.com/airbnb/ts-migrate may speed few migration steps (but it wont solve missing types/interfaces)

You can use AirBnb's ts-migrate tool or try a more direct tactic following the Migrating from JavaScript guide.

Take a look at https://github.com/airbnb/ts-migrate

A parser can have various applications in everyday life, and you probably use some parser daily. Babel, webpack, eslint, prettier, and jscodeshift. All of them, behind the scenes, run a parser that manipulates an Abstract Syntax Tree (AST) to do what you need - we'll talk about that later, don't worry.

OP: If this is an avenue you feel like entertaining, here are some nice codemod tools that could ease the transition for you: CodeQue, Subsecond, and the old standard jscodeshift.

If that isn't enough or you find issues with it, the current de-facto standard for codemods is jscodeshift. You'll write more code, but at least you only have to write it once.

Here is the pull request https://github.com/facebook/jscodeshift/pull/549

Those are important but tough problems!

1. I feel like codemods and a setup shell prompt are the best solution to this, but this looks different for each language (eg, in JS there is https://github.com/facebook/jscodeshift). I could make UI around that for listers to provide parts of the app that should replaced and buyers to provide values for it, but it could be quite a rabbit hole. This is actually why I show the README for the repos, so users can see if the setup steps are comprehensive before buying (for paid ones).

2. I agree atomic commits can help someone navigate a new codebase. In the same spirit as my response to #1, I don't feel confident I could enforce this, but I could surface the commits on the starter repo page so potential buyers could see if the author laid things out well.

Thanks for the ideas!

That's why I've been working on a tool that automatically upgrades major versions of libraries with breaking changes, the idea is to simplify the process and save developers time and effort by having a bank of transformers (using codemod & jscodeshift) and open source them:

JSCodeshift: A toolkit for running and writing codemods.

jscodeshift