Job typescript-incremental-module-conversion · revised 11 October 2026

Convert one JavaScript module to TypeScript with strict checks on that folder only

Convert one named folder of a JavaScript codebase to TypeScript under strict checking, with the rest of the code untouched, the tests passing and the type check running in CI.

You might be seeing

The same kind of bug, such as a missing property or a wrong argument type, keeps returning in one area
Nobody is sure which fields a core object has without reading the code that builds it
A previous attempt to add TypeScript to the whole project stalled on thousands of errors

Enquire — from £595 Check if it fits first What to send us

No passwords, keys, card details or admin invites needed to start.

From £595

Final price agreed before we start

From £595 for one folder within those limits. We read the folder and its boundary before a final fixed quote. A tangled boundary, missing tests or a folder much larger than the limit lead to a separate decision or a stop.

You pay: After the agreed checks pass and you sign off. No advance payment.
Includes: One folder of up to 30 files and about 4,000 lines converted to TypeScript; Strict checking for that folder only, with typed exports and boundaries; A type-check step in CI and a report of remaining escape hatches
Technology: TypeScript, JavaScript, npm
Delivery: Start window and delivery date agreed in writing after eligibility and access checks.

This is a new fixed-price service. We agree scope and checks with you before starting, and you pay after it works and you sign off.

Enquiry only: no checkout, charge or booking. The written quote confirms the total price and any applicable tax before you accept.

What usually happened

Converting a whole JavaScript codebase at once produces thousands of errors and stalls. TypeScript can be adopted folder by folder, because it can include JavaScript files alongside TypeScript and can check JavaScript files on request, but a half-done conversion is easy to get wrong: files renamed with the strict flags off, types added as any that check nothing, comments that silence errors, or a build that cannot read the new files. The folder is then called converted without being safer.

Who it’s for: A founder or engineering lead who wants TypeScript's checks on the part of the code that causes the most bugs, without stopping feature work for a whole-codebase conversion.

Usually starts when: A bug traced to a wrong argument or a missing field in one area keeps recurring, a new hire asks for types on the core module, or an earlier all-at-once conversion stalled.

The result: One named folder is TypeScript. It passes the compiler with strict checking enabled for that folder, its public exports carry real types rather than any, the boundaries with the rest of the code are typed, a type-check step runs in CI, and the existing tests pass unchanged. Code outside the folder behaves as before.

Check whether this job fits

Five short questions. Your answers stay on this page unless you choose to email them.

How big is the folder you want converted?

Up to 30 files, about 4,000 lines Larger Not sure

Are there tests that cover that folder?

Yes Partly or not at all

How does the project build or run its JavaScript?

A bundler such as Vite, esbuild or Webpack, or Node directly Something custom

Does the folder have a clear public interface?

A set of functions or classes that the rest of the code imports, rather than other code reaching into its internals.

Yes, mostly No, everything reaches into everything

Who will review the types?

A developer on our team Nobody technical

Answer the questions to see whether this job fits.

Nothing is sent anywhere until you choose to email us.

Send an enquiry about this outcome

How to read your answers: any answer below means this fixed job needs a closer look or doesn’t fit.

How big is the folder you want converted? Larger: The fixed scope covers one folder within that size. Larger areas are split into folders or quoted separately; send the counts.
How big is the folder you want converted? Not sure: Count the files and lines; see the self-check below.
Are there tests that cover that folder? Partly or not at all: Conversion should not change behaviour, and tests are how that is shown. Without them acceptance rests on a written list of checks run by hand, and the price may change.
How does the project build or run its JavaScript? Something custom: Describe it. If TypeScript files cannot be fed to it without a larger change, that becomes a separate decision.
Does the folder have a clear public interface? No, everything reaches into everything: The conversion types what crosses the boundary. A tangled boundary may need refactoring first, which this job does not do.
Who will review the types? Nobody technical: Types encode decisions about the data. Name who can confirm them before we start.

Checks you can run yourself

Count files and lines in the folder
Run this in a copy of the project folder, replacing the folder name, and send the two numbers.
```
find src/FOLDER -name "*.js" | wc -l; find src/FOLDER -name "*.js" -exec cat {} + | wc -l
```
Look for: The number of files and the number of lines. The fixed scope covers up to 30 files and about 4,000 lines.
See whether TypeScript is already installed
Run this in a copy of the project folder.
```
grep -E "\"typescript\"" package.json
```
Look for: A line with a version number, or nothing. Send what you see.

What you get

The converted folder and configuration as a pull request
A report of the remaining escape hatches: each any or error-suppression comment, with the reason
The CI change that runs the type check, and a note on how to extend the strict area to the next folder

Included

One named folder of up to 30 source files and about 4,000 lines of JavaScript, plus its test files
A TypeScript configuration that lets JavaScript and TypeScript files coexist, and a stricter configuration that applies the strict family of checks to the converted folder only
Renaming files one at a time and fixing each error with a real type, using type declarations for dependencies that have them
Types for the folder's public exports and for the data shapes that cross its boundary, such as function inputs and API responses
The minimum build support so the project's existing build tool can read the converted files, and a type-check command added to CI

Not included

Converting the rest of the codebase, or turning on strict checking project-wide
Refactoring or changing what the code does
Runtime validation of external data, which types do not provide
Changing the bundler, the test runner or the framework
Writing type declarations for a dependency that has none, beyond what is needed at the folder's boundary

How we know it’s done

Agreed with you before work starts. Each check produces evidence you keep.

The type-check command, run with strict checking for the converted folder, finishes with no errors and emits no files
Evidence: The command output and the configuration that applies the strict settings to the folder
```
npx tsc --noEmit -p tsconfig.strict.json
```
No exported function, class or value of the converted folder has any as its type, and every suppression comment or any inside the folder is listed in the report with a reason
Evidence: A search result showing zero exported any, and the escape-hatch report
The existing tests pass unchanged before and after the conversion, and the project's build finishes with the converted files included
Evidence: Test and build output for the baseline and the final state
The CI pipeline runs the type-check command and fails when a type error is introduced in the converted folder
Evidence: A CI run that passes on the change, and a run on a deliberately broken branch that fails, linked in the handover

Sign-off. You review the pull request, the escape-hatch report and the CI evidence, then merge and deploy under your own gates. Types describe the code's expectations; they do not validate data arriving at runtime.

If it fails. If the agreed acceptance checks do not pass, you do not pay and you keep our configuration and findings.

When it fits, and when we stop

It fits when

The folder is JavaScript, with ES modules or CommonJS, and has up to 30 files and about 4,000 lines
There are tests that exercise the folder's behaviour, or you accept a written list of checks instead
The project has a build or run step that can be extended to read TypeScript, or the files run through a bundler
A person on your side can review the pull request and decide each recorded escape hatch

We stop and tell you if

The folder depends on code outside it in so many circular ways that it cannot be typed without refactoring
The code relies on dynamic behaviour, such as properties added in many places at runtime, that cannot be typed without changing it
The project cannot run its tests on a copy
The folder is larger than the agreed limit and the owner does not accept a split

What could go wrong

The change is a pull request your team merges, so it can be reverted like any other. Files are renamed in separate commits so one can be undone without the rest.

Scroll the table sideways to read it all.

Risk	How we handle it
Types are written to make errors disappear rather than to describe the data	The acceptance check counts any in exported signatures and every suppression comment, and the reviewer reads each against the code that uses it.
The conversion changes runtime behaviour	The existing tests run unchanged before and after, and the change is limited to renames, types and build support.
A type is correct today but wrong for data the code receives from outside	The report states which types describe external data and says that types are not checked at runtime.

A second reviewer reads every exported type against how the rest of the code uses it, checks that suppressions and any are each justified in the report, and re-runs the type check from the handover notes alone.

How we deliver

We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.

Agree the folder, the definition of done and the strictness settings, then run the tests and the build on a copy and record the baseline
Add a TypeScript configuration that lets JavaScript and TypeScript coexist and a stricter one for the folder, with the type check running without emitting files
Rename the folder's files one at a time, give each export and boundary a real type and fix each error with a type rather than a suppression
Add the minimum build support so the existing build tool reads the files, then re-run the tests and the build
Add the type-check step to CI and record every remaining any or suppression comment with its reason
Independent review of the types and the escape-hatch report, then hand over the pull request with the evidence and the steps to revert it

This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.

Need to keep it working?

Discuss a follow-on to convert the next folder, or a monthly service that keeps dependencies on supported versions.

Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.

Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.

What you can check

This is a new service. We have not delivered this job for a client yet.

Other ways to get this done

TypeScript can check JavaScript files in place: a comment at the top of a file turns checking on for that file, and a project setting turns it on for all JavaScript files. If you only want to find errors, starting there needs no renaming. www.typescriptlang.org
The TypeScript handbook describes migrating a JavaScript project by letting JavaScript be compiled alongside TypeScript and renaming files one at a time. A team with time can follow it directly. www.typescriptlang.org

Questions

Why only one folder?

A small converted area finishes and can be judged. It also leaves you a working pattern, the configuration and the CI step, for converting the next folder yourselves or with another job.

Will the types catch bad data from my API?

No. Types are checked when the code is compiled, not when it runs. Checking incoming data at runtime is a separate piece of work.

Can you just turn on strict mode for the whole project?

That usually produces a long list of errors across code nobody has reviewed. Applying strict checks to one folder at a time keeps the number of errors manageable.

Send an enquiry

Send us

The folder to convert, its approximate file and line counts, and what it does
How the project is built and run, and the Node.js version
Whether TypeScript is already installed anywhere in the project
The bugs or confusions that motivated the conversion

Later, once you agree

A controlled copy of the source with secrets removed, through the agreed company-controlled secure handoff
How to run the tests, the build and the linter
Any style or strictness rules your team already prefers for TypeScript
A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.

You own the code, build pipeline and hosting. We work from an authorised copy with secrets removed and return a pull request that your team reviews, merges and deploys. We never ask for passwords or tokens in the first enquiry.

Email fallback: open your mail app

If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “typescript-incremental-module-conversion” as the subject.