TypeScript Adoption Rate Among Top npm Packages
·PkgPulse Team
TL;DR
TypeScript has won the npm ecosystem at the top. 95% of the top 100 packages either ship TypeScript types or have high-quality @types/ support. But adoption falls off rapidly in the long tail — only ~40% of all npm packages have any TypeScript support. The gap between top packages and average packages has never been larger, and it's accelerating as TypeScript-first packages consistently outperform JavaScript-only alternatives.
Key Takeaways
- Top 100 packages: 95% TypeScript support (bundled or @types/)
- Top 1,000: 89% TypeScript support — the professional tier
- All packages: ~40% TypeScript — long tail is still mostly JS
- TypeScript-first (bundled types) vs @types/ is growing: 78% bundled among typed packages
- TypeScript usage: ~68% of JS developers use TypeScript (State of JS 2025)
The Adoption Curve
TypeScript support across npm (2016-2026):
Year Top 100 Top 1000 All packages
2016: 25% 15% 5%
2018: 45% 30% 12%
2020: 65% 50% 22%
2022: 80% 70% 32%
2024: 90% 82% 38%
2026: 95% 89% 42%
Observations:
→ Top packages: near-universal TypeScript (95%)
→ Long tail: growing but slower (only 42%)
→ The gap is widening: top packages normalized TS; long tail catching up slowly
Why the top converged faster:
→ High-profile packages face developer pressure ("why no types?")
→ Open source maintainers are power users who want types
→ GitHub issues and PRs: TypeScript type requests are common
→ "TypeScript TS" badge on npmjs.com → download signal
TypeScript Support by Package Category
TypeScript adoption rate by package category (2026):
State management: 100% (zustand, jotai, valtio, redux-toolkit, xstate)
Build tools: 99% (vite, esbuild, rollup, webpack types, rspack)
Testing: 98% (vitest, playwright, testing-library, jest via @types)
Validation: 100% (zod, valibot, arktype, yup via @types)
ORM / Database: 95% (prisma, drizzle, mongoose via @types, knex)
HTTP clients: 92% (fetch, axios, ky, undici, ofetch all typed)
Web frameworks: 90% (hono, fastify, express via @types, koa)
Date libraries: 95% (dayjs, date-fns, luxon, temporal polyfill)
Auth: 90% (clerk, auth.js, lucia — all TypeScript-first)
CSS-in-JS: 85% (styled-components, emotion, panda css)
Charting: 75% (recharts, chart.js, d3 — d3 is complex types)
CMS integrations: 70% (varies widely)
Legacy utilities: 55% (many old utility packages still JS-only)
Unmaintained packages: <30% (abandoned packages rarely got types)
TypeScript-First vs @types/ Packages
// The distinction matters for quality:
// TypeScript-first: types are part of the package, maintained together
// package.json: "types": "dist/index.d.ts"
// Types updated with every release
// Types are tested in the same test suite
// Examples: Zod, Zustand, Fastify, TanStack Query, Drizzle, Hono
// @types/: maintained separately on DefinitelyTyped
// Separate repo, separate contributors, can lag behind
// Types might be 1-2 minor versions behind
// Examples: @types/express, @types/node, @types/react
// The quality gap:
// TypeScript-first packages: types are usually precise and correct
// @types/ packages: quality varies widely
// - @types/react: excellent (maintained by dedicated community)
// - @types/node: excellent (Microsoft maintains)
// - @types/some-old-library: may be years out of date
// How to tell which you're getting:
npm view package-name --json | jq '.types, .typings'
// Returns path → TypeScript-first
// Returns null → check for @types/package-name on npm
Packages That Made the TypeScript Transition
# Early JavaScript-only packages that added TypeScript support:
# axios: v0.x was JS-only
# axios@0.20: bundled .d.ts files
# axios@1.0: full TypeScript rewrite of types
# Now: excellent TypeScript support, built-in
# lodash: added types via @types/lodash (community effort)
# lodash/fp types: separate @types/lodash-fp
# Still @types/-based but high quality (very widely used = well maintained)
# express: still @types/express
# express v5 (finally): improved API but still relies on @types/
# @types/express is maintained by the community, surprisingly good quality
# mongoose: added TypeScript support in v6+
# mongoose@6+: built-in types, model generics, query typing
# Before v6: only @types/mongoose (often wrong for complex queries)
# socket.io: excellent TypeScript support since v4
# Generic types for event names and payloads:
import { Server, Socket } from 'socket.io';
type Events = { message: (text: string) => void; join: (room: string) => void };
const io = new Server<Events>(); // Fully typed event names and payloads
Developer Usage Data
TypeScript usage (State of JS 2025):
"I use TypeScript" (by self-report):
→ Yes, exclusively: 45%
→ Yes, with JavaScript: 23%
→ No, but plan to: 14%
→ No, don't plan to: 18%
Total TypeScript users: ~68% (up from 45% in 2020)
By company size:
→ Startups (1-10): 60% use TypeScript
→ Mid-size (11-200): 75% use TypeScript
→ Enterprise (200+): 85% use TypeScript
By developer tenure:
→ <2 years experience: 45% TypeScript
→ 2-5 years: 65% TypeScript
→ 5-10 years: 72% TypeScript
→ 10+ years: 65% TypeScript (some "I prefer plain JS" in senior devs)
Why TypeScript adoption keeps growing:
1. AI code editors: Copilot, Cursor suggest type-safe code
2. Error catching: TypeScript catches entire classes of bugs at compile time
3. Refactoring: type-safe refactoring is dramatically safer
4. Self-documenting: types replace many code comments
5. Ecosystem: TypeScript-first libraries have better DX
The JsDoc Alternative
// Not everyone uses TypeScript — some use JSDoc for types
// JSDoc: type annotations in JavaScript comments, parsed by TypeScript
/** @type {import('express').Request} */
const req = getRequest();
/** @param {string} name @returns {string} */
function greet(name) {
return `Hello, ${name}!`;
}
// Downside of JSDoc vs TypeScript:
// → More verbose than TypeScript type syntax
// → Limited generics support
// → Can't import complex types as cleanly
// → Not enforced at file boundaries
// Who uses JSDoc:
// → Packages targeting multiple environments (some don't want TS build step)
// → Legacy codebases adding types incrementally
// → Projects where "zero build" matters (direct browser scripts)
// The trend: TypeScript is winning decisively over JSDoc
// JSDoc: ~12% of typed packages (down from 25% in 2020)
// TypeScript: ~88% of typed packages (up from 75%)
The TypeScript "Tax" That Isn't
// Common objection: "TypeScript adds complexity"
// Reality: TypeScript REMOVES complexity at scale
// Compilation step: true cost
// → tsc or vite/esbuild compile step
// → Adds 1-30 seconds to builds (parallel, so often negligible)
// → Type checking: separate from compilation (esbuild skips type-check)
// IDE support: massive productivity gain
// → Autocompletion for every import, every method
// → Inline error detection before running code
// → Safe rename refactoring across entire codebase
// Type errors found: average project
// → Converting JS codebase to strict TS:
// typically finds 5-20% of function calls with wrong argument types
// typically finds 10-30% of property accesses that could be undefined
// → Most of these become real runtime bugs eventually without TypeScript
// The real cost: strictness config
// tsconfig.json "strict: true" is uncomfortable for JS developers at first
// But teams that do it: significantly fewer production type errors
// Teams that don't: get TypeScript with the safety net partially removed
// Verdict: TypeScript's "tax" is a one-time learning cost
// Its benefit is continuous: every type error caught = one fewer bug
Compare TypeScript support and package health at PkgPulse.
See the live comparison
View typescript vs. jsdoc on PkgPulse →