Adding TypeScript to an existing Node.js project sounds simple until it isn’t.
A few files in, things usually start drifting:
- tsconfig.json stops matching the actual runtime
- CommonJS and ESM start fighting each other
- mixed .js and .ts files make the project harder to reason about
- test and lint setup adds even more friction
I kept running into that same wall, so I built a small CLI to make the setup predictable.
What it is
fast-ts-integrator is a CLI that helps add TypeScript to a new or existing Node.js project with an interactive setup.
It lets you choose:
- ES Modules or CommonJS
- tsx or ts-node
- Biome or ESLint + Prettier
- Vitest or Jest Then it installs what is needed, generates the config, and adds the scripts so you can actually start working instead of fighting setup.
Why I built it
Most of the pain was never “TypeScript itself”.
It was the setup around it:
- choosing the right module strategy
- keeping runtime behavior consistent
- avoiding broken imports after migration
- wiring linting and testing without turning the project into config soup
I wanted something practical that works for real Node.js projects, not just empty demos.
Quick start
npx fast-ts-integrator
or
npx fast-ts
Example flow
The CLI walks through a few choices:
- module system
- execution engine
- linter/formatter
- test framework
After that, it scaffolds the setup and updates package.json for you.
Links
npm: npm package
GitHub: Github Repo
Still improving
This is an early release, and I’m actively improving it.
Real feedback would help a lot, especially from people who have dealt with:
- gradual JS to TS migration
- CommonJS to ESM headaches
- existing Express or Node backends
- lint/test setup that tends to break during migration
If you try it, I’d genuinely like to know what feels smooth and what feels annoying.
Top comments (2)
The insight: "Most of the pain was never TypeScript itself, it was the setup around it." That's true for almost every tool. The language isn't the problem. The config sprawl, the module resolution wars, the test runner that suddenly doesn't understand imports, that's where projects die. You didn't build a TypeScript tool. You built a decision recorder for choices most developers make once and then forget why. The CLI doesn't just configure. It commits those decisions to config files so the next person doesn't have to relitigate them. That's not automation. That's institutional memory.
Appreciate this a lot.
That was exactly the pain I kept running into. TypeScript itself was rarely the issue. It was all the surrounding decisions that kept getting rebuilt from scratch in every project: module system, tsconfig, path aliases, test setup, build flow, import behavior, all of it.
I wanted a tool that doesn’t just “add TypeScript”, but preserves those choices in a way that’s repeatable and less fragile for the next person touching the codebase.
“Institutional memory” is a really good way to put it. That’s honestly closer to the goal than simple automation.
Thanks for reading it that closely.☺️