Solution · JS to TypeScript
Migrate components from JS to TypeScript
Connect your repo and name the components to convert. The agent adds real types, fixes the fallout, verifies the build, and opens a pull request you can review.
For developers · connect a repo → reviewed pull request
At a glance
Is this the right pattern for you?
The short version, before the detail — who this is written for, what you start from, and what exists at the end.
| This solution | |
|---|---|
| Written for | Developers with an existing codebase |
| You start from | A GitHub repository and a change you want made |
| You end up with | A scoped, verified pull request awaiting your review |
| The path runs | Connect → index → edit → verify → pull request |
| Built on | Code intelligence · Sandbox verification · GitHub PR agent |
| Plan needed | Pro — GitHub repositories and pull requests are a Pro capability |
No timings are quoted anywhere on this page, because how long a build takes depends entirely on what you asked for.
The challenge
Why this is usually hard
Worth understanding before the how — because the reason this is difficult is not the reason most people assume.
Converting a component to TypeScript is not a rename, and the projects that stall are the ones that treated it as one. Props need types that reflect what callers actually pass. Shared shapes have to be inferred from usage rather than invented. And the moment a file gains types, every consumer of it can sprout new errors — which is not a defect, it is the migration doing its job, but it means the unit of work is never a single file.
That leaves two bad options. Piecemeal migration stalls, because each small conversion drags in unbounded downstream fixes and the person doing it runs out of afternoon. One giant manual pass produces a diff nobody can review, which gets approved on trust and quietly introduces the sort of mistake types were supposed to prevent.
There is a third failure mode that is more common than either: migrating by adding `any`. The files gain a .ts extension, the build goes green, and none of the safety arrives. It looks like progress on a burndown chart and delivers nothing, and it is very hard to undo later because the escape hatches are now load-bearing.
How it works
From a connected repo to a reviewed PR
Every stage in order, including the ones that happen without you asking.
- 1
Connect your repository
$ connect repoPoint the agent at your GitHub repository. It operates against a clone, so your branches are untouched, and the connection can be scoped or revoked whenever you want.
- 2
Choose the scope yourself
$ migrate these components to TypeScriptName the components or the folder to migrate. Scope is the main lever you have over how reviewable the result is, and keeping it deliberate is what turns a stalled migration into a series of pull requests that actually land.
- 3
Usage is indexed before types are written
The repository is indexed semantically and by symbol, so the agent can see how each component is actually called across the project. Types inferred from real usage are the difference between a migration that adds safety and one that adds ceremony.
- 4
Real types, written in a sandbox clone
Files are renamed, prop and state types are inferred from how the code is genuinely used, and shared type definitions are added where several call sites want the same shape. The goal is meaningful types rather than blanket escape hatches.
- 5
Downstream fallout is resolved in the same pass
Type errors that ripple into consumers of a converted file are handled as part of the change, not left for whoever runs the build next. This is the work that makes piecemeal migration stall, and it is the reason the unit of work has to be bigger than one file.
- 6
Typecheck, tests and build all have to pass
verifyThe gates run against the clone. For this task typecheck is not a formality — it is the actual acceptance criterion, since the entire point of the change is that the compiler now has something true to check.
- 7
A scoped pull request arrives
$ open prYou get a pull request limited to the migration you asked for, with a summary of what was typed. Your repository changes when you merge it, and not before.
Why code-anything
What you get out of the box
Not a feature list — the specific things this pattern removes from your side of the work.
Real types, not blanket any
Props and shared shapes are inferred from how the code is actually used across the project. A migration that reaches for escape hatches passes the build and delivers none of the safety that justified the work.
Ripple effects handled in the same change
Symbol-aware indexing tracks every consumer of a converted file, so the errors that surface downstream are resolved as part of the pass rather than discovered by the next person to run the build.
The build stays green
Typecheck, tests and build all run against the sandbox clone before anything is offered, so the pull request arrives compiling cleanly under TypeScript.
A scoped, reviewable pull request
The change is limited to the migration you asked for and not mixed with unrelated tidying, which is what makes the diff something a reviewer can genuinely read rather than approve on faith.
A migration you can do incrementally
Because you set the scope and each pass is independently verified, a large migration becomes a sequence of landable pull requests instead of one enormous branch that drifts out of date.
Nothing lands without your merge
All the work happens in an isolated clone and reaches your repository only through a pull request. A migration attempt you dislike costs you a read and leaves nothing behind.
In practice
What it looks like
Two lines in that flow describe the work that actually makes a TypeScript migration succeed: inferring types from real usage, and resolving what breaks downstream as part of the same change.
Skip the first and you get `any` with extra steps. Skip the second and the migration stalls, because every small conversion leaves a trail of errors for someone else to trip over. The typecheck gate at the end is not ceremony here — it is the acceptance criterion for the entire task.
$ connect repo acme/web-app
$ migrate these components from JS to TypeScript
✓ indexed component usage across the repository (semantic + symbol)
✓ converted to .tsx, inferred prop and state types from usage
✓ resolved type errors in downstream consumers
✓ typecheck · tests · build all pass
→ opened a pull request "Migrate components to TypeScript"What you get
- The components you scoped, converted to TypeScript with real types
- Prop and shared types inferred from actual usage rather than blanket any
- Downstream type errors in consuming files resolved in the same change
- Typecheck, tests and build passing against the migration
- A pull request limited to the migration, with a summary of what was typed
- A repeatable pass you can run again on the next folder
What it involves
The honest shape of the path
Stage by stage: what the platform does, and what is genuinely still asked of you.
| Stage | What actually happens | What is asked of you |
|---|---|---|
| Connect | You authorise a GitHub repository. Nothing is written to your branches. | One authorisation, scoped and revocable. |
| Index | The repository is indexed semantically, so behaviour can be found without a file name, and by symbol, so the agent knows what a definition is used by. | Nothing. This runs on connection, before any change is proposed. |
| Edit | The change is made inside an isolated sandbox clone of your repository. | A description of the change in your own terms — not a list of files. |
| Verify | Typecheck, tests and build run against the clone. If a gate fails, the agent keeps working rather than handing you broken code. | Nothing, though the value of this step is bounded by how real your own checks are. |
| Pull request | A scoped pull request is opened with a summary of what changed. | A review, and the merge — which is the only moment your repository changes. |
The stage names above are the product’s own: connect, index, edit, verify, pull request. How long a pass takes depends on the repository and the change, so no figure is quoted here.
Connecting a GitHub repository and opening pull requests is a Pro-plan capability, so this path needs Pro. Sandbox verification — typecheck, tests and build running before you see a change — is included on every plan. See the full plan comparison.
What you own
What you are left holding
On a codebase that already exists and already matters, the interesting question is not how fast a change can be produced but what is true about it by the time you are asked to look at it. Here is exactly what the arrangement guarantees, and what it deliberately leaves to you.
What is true before you see it
- Every edit happened in an isolated sandbox clone, never in your repository
- Your own typecheck, tests and build were run against the change and passed
- The work is scoped to what you asked for rather than mixed with unrelated tidying
- The pull request carries a written summary of what changed and why
What stays your decision
- Whether to merge — a pull request is a proposal, and your repository is unchanged until you accept it
- The agent never pushes to your branches and nothing is merged on your behalf
- You can leave a pull request unmerged at no cost beyond the time spent reading it
- The GitHub connection is yours to scope or revoke whenever you want
FAQ
Common questions
Keep looking
Other reference patterns
Every solution is a worked end-to-end example. If this one is not quite your situation, one of these probably is.
Add dark mode
Connect your GitHub repo and ask for dark mode. The agent indexes the code, makes the change in a sandbox, verifies it builds, and opens a pull request for you to review.
For developersFix failing tests
Connect your repo and point at the broken test. The agent reproduces the failure, finds the cause, fixes it, re-runs the suite green, and opens a pull request.
For developersOr the other way of working — describe an app in plain English and get a live, hosted result:
Bakery website
Describe your shop in plain English and watch a real website build itself in a live preview — complete with a contact form that emails you every enquiry.
For anyoneBooking app
Describe the booking flow you want and get a working app — a calendar customers book into and an email confirmation sent on every appointment, all wired up for you.
For anyoneStripe dashboard
Describe the numbers your team cares about and get a private dashboard — revenue, growth and customers — with sign-in, built without touching a line of code.
For anyoneBuild js to typescript the way it should have been.
Connect a repository and describe the change. Every edit happens in an isolated clone, clears your own typecheck, tests and build, and arrives as a pull request you review.