Why we built CodeMorph

Almost every team with a large JavaScript codebase has had the same meeting. Someone makes the case for TypeScript: fewer production bugs, safer refactors, editors that actually know what a function returns. Everyone agrees. A migration starts.

Then it stalls. A few files get converted, tsconfig.json grows a long list of exceptions, and a year later the codebase is two languages held together by any.

CodeMorph exists because we think that stall has a specific, fixable cause.

Conversion was never the hard part

Renaming .js to .ts is trivial. Adding type annotations is tedious, but it's the kind of tedious that tools can help with. The tools already exist:

• Rename and suppress. Flip every file to TypeScript and silence the errors with // @ts-nocheck or any. It compiles on day one, and the types are fiction.
• Codemods. Automated tools convert files mechanically and insert any and @ts-expect-error wherever inference fails. Faster, same result.
• AI assistants. Paste a file into a chat, get TypeScript back. It looks great, until you notice the model invented the shape of every import it couldn't see.

Each approach produces TypeScript. None of them can tell you whether the result is right: whether the types describe what the code actually does, and whether the app still works.

So teams do the only safe thing, which is review every file by hand. That's the stall.

Two ideas

CodeMorph is built on two ideas that sound obvious once you say them out loud.

Order matters. Types flow upward through imports. If you convert models/order.js before lib/db.js, the model has to guess what db.find() returns. If you convert lib/db.js first, verify it, and then convert the model, the answer is sitting right there in a typed file. So CodeMorph builds a dependency graph of your project and migrates leaf modules first, batch by batch, until it reaches your entry point.

Verification is the product. A converted file isn't done when it parses. It's done when the TypeScript compiler reports zero errors across the project and your own test suite still passes. CodeMorph runs both after every batch, sends compiler errors back for repair, and flags anything it can't fix cleanly instead of papering over it with any.

Put those together and you get something new: a migration where every step is checkable, so you can trust the result without re-reading every line.

Why an editor

We could have built a CLI or an extension. We built an editor because a migration isn't one command. It's a graph to explore, a plan to adjust, diffs to review, a terminal to run tests in, and questions to ask along the way. That workflow deserves a home with room for all of it.

CodeMorph is a complete desktop editor with the keybindings and layout developers already know, so it feels familiar from the first minute. The migration engine and the Morph agent are built into the layout, not bolted onto the side.

What we won't compromise on

• Your code stays on your machine. Scanning and planning are local. When AI features arrive, you bring your own key and requests go straight to your provider. Or run models locally with Ollama.
• No fake progress. If a file needs a human, CodeMorph says so.
• Honesty about the beta. The changelog and these docs say exactly what ships today and what's coming.

Built in Lagos

CodeMorph is built in Lagos, Nigeria. Developer tools that teams around the world rely on can come from anywhere, and we intend to prove it with craft rather than claims.

Where we are

The beta is out for Windows. Point CodeMorph at a JavaScript project and in seconds you'll see its dependency graph and a leaf-first plan. Start the migration, review every file as a diff, and run Verify to prove the result typechecks, passes your tests and builds.

If you've lived through a stalled migration, we'd love for you to try the beta and tell us what you find.