TypeScript Is #1 on GitHub in 2026: Why AI Made It Happen

TypeScript hit #1 on GitHub in 2026 — and if you haven’t noticed the shift in your team’s conversations yet, you will soon. According to GitHub’s Octoverse 2025 report, TypeScript reached 2,636,006 monthly contributors in August 2025, overtaking both Python and JavaScript for the first time. That’s a 66% year-over-year jump — the biggest single-year language shift GitHub has recorded in over a decade. The obvious explanation is that frameworks like Next.js and Astro default to TypeScript now. But that only tells half the story. The real driver is AI, and the relationship between AI coding tools and static typing is more interesting — and more counterintuitive — than you might expect. This post explains why it happened, what it means for your day-to-day work, and the specific tsconfig settings you should have in every project right now.

Why did TypeScript suddenly become the #1 language on GitHub?

Three things happened at roughly the same time, and they compounded each other.

First, the major frontend frameworks all defaulted to TypeScript. When you scaffold a new Next.js 15, SvelteKit 2, Astro 3, or Qwik project today, you get TypeScript out of the box. New developers don’t choose TypeScript — they just get it, and they never look back.

Second, every major LLM SDK is now TypeScript-first. The OpenAI Node.js client, Anthropic’s SDK, LangChain.js, and Vercel’s AI SDK all ship TypeScript types as the primary interface. Developers building anything with AI are writing TypeScript whether they set out to or not.

Third — and this is the part most analyses miss — GitHub’s Developer Advocate Andrea Griffiths identified a “convenience loop” in the Octoverse data. AI coding assistants make TypeScript feel easier to write because they generate better suggestions in typed codebases. More developers pick TypeScript as a result. That generates more TypeScript training data for the AI models. Which makes them even better at TypeScript. The loop feeds itself.

TypeScript added over one million new developers in 2025. Python added 850,000. JavaScript added 427,000. The gap will keep widening.

How do AI coding tools actually make TypeScript more valuable?

AI assistants like GitHub Copilot and Cursor read your type signatures the same way a human reader does — as documentation. When you write a function that accepts a UserProfile type and returns a Promise<OrderSummary>, the AI knows exactly what it can put in and what it should return. It stops hallucinating wrong method names or incorrect property shapes because the types constrain the output space.

In a plain JavaScript file, the AI is essentially guessing. It might autocomplete user.name when the object is actually user.fullName, and you won’t find out until you run the code. In a TypeScript file, the compiler and the AI are both working from the same contract.

// TypeScript with types — the AI generates this correctly every time
async function getOrderSummary(userId: string): Promise<OrderSummary> {
  const user = await fetchUser(userId); // TypeScript knows fetchUser returns User
  const orders = await fetchOrders(user.id); // .id is valid — TypeScript confirms it
  return summariseOrders(orders); // return type checked against OrderSummary
}

// Plain JavaScript — the AI has to guess shapes from context alone
async function getOrderSummary(userId) {
  const user = await fetchUser(userId); // what does fetchUser return?
  const orders = await fetchOrders(user.id); // does .id exist? who knows
  return summariseOrders(orders);
}

A 2025 academic study found that 94% of LLM-generated compilation errors were type-check failures. TypeScript’s type system catches those mistakes before they leave your editor, rather than at 2am when a production alert fires. That’s not a minor convenience — it fundamentally changes the risk profile of AI-assisted development.

When building projects that touch AI models, pair TypeScript with Zod for runtime schema validation. The two together give you static types at compile time and shape guarantees at runtime — exactly what you need when parsing LLM responses that don’t always match the schema you expect.

What tsconfig settings should you use in 2026?

Start here: enable strict: true. If your project doesn’t have this, fix it before you do anything else.

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "moduleResolution": "bundler",
    "target": "ES2022",
    "lib": ["ES2022", "DOM"],
    "noEmit": true
  }
}

strict: true turns on eight flags at once, including strictNullChecks, noImplicitAny, and strictFunctionTypes. Without these, TypeScript misses entire categories of bugs — null-pointer crashes, functions called with the wrong argument types, unintentional any spreading through your codebase like an infection.

The flag most guides leave out is noUncheckedIndexedAccess. It’s not included in strict: true, so you have to add it manually. What it does: when you access an array by index (items[0]) or an object by key (map[key]), TypeScript normally tells you the result is type T. With noUncheckedIndexedAccess enabled, it tells you the result is T | undefined — forcing you to handle the case where nothing was there. This catches a whole class of runtime crashes that strict mode alone won’t catch. Enable it on every new project from day one.

One important note on noEmit: true: if you’re using Next.js or Vite, this is correct — those tools handle transpilation themselves. Running tsc directly produces no output files. This surprises developers who expect a dist folder. If you need compiled output (for a Node.js backend or CLI tool), remove noEmit and set outDir instead. This pattern is similar to how Vite 8 and Rolldown changed build defaults — small config choices with big runtime consequences.

For module resolution: use "bundler" if your project uses Vite, Next.js, or Remix. Use "NodeNext" for pure Node.js projects. Using the wrong one causes import resolution errors that are cryptic and wasteful to debug.

What are the production gotchas TypeScript developers hit most?

The biggest one, and the one that bites even experienced TypeScript developers: JSON.parse() returns type any, even in strict mode.

// This compiles with zero errors — and can crash at runtime
const data = JSON.parse(response); // type: any
console.log(data.user.name); // TypeScript does not check if .user or .name exist

// The correct approach: validate the shape at runtime
import { z } from 'zod';

const UserSchema = z.object({
  user: z.object({
    name: z.string(),
    email: z.string().email(),
  }),
});

type UserData = z.infer<typeof UserSchema>; // TypeScript type derived from schema

const data: UserData = UserSchema.parse(JSON.parse(response)); // runtime + static safety

The same issue applies to fetch().json(). The response is any by default. When you’re parsing LLM API responses, webhook payloads, or third-party API calls, always validate the shape at runtime with Zod or a similar library before handing it to your typed application code.

The second gotcha: type assertions with as. When you write const user = {} as UserProfile, TypeScript trusts you completely — it stops checking. If the object doesn’t actually have the methods or properties of UserProfile, you’ll get a runtime error the first time you use one. Use as sparingly, and prefer type narrowing with type guards instead.

The third gotcha hits teams migrating existing codebases: running with strict: false long-term to ease migration. Non-strict TypeScript catches maybe 30% of the bugs strict TypeScript catches. Migrate incrementally using // @ts-ignore or // @ts-expect-error on problem spots, then clean them up file by file — rather than running the entire codebase in lenient mode forever. For a parallel lesson in how small runtime configuration gaps cause security failures, see our post on Node.js permission model gotchas.

How does TypeScript compare to JavaScript for new projects in 2026?

TypeScript adoption among professional developers reached 78% in 2026, up from 69% in 2024. The question for most teams isn’t whether to use TypeScript — it’s whether to use strict TypeScript or permissive TypeScript. The gap between those two is larger than the gap between TypeScript and JavaScript.

Factor	Plain JavaScript	TypeScript (non-strict)	TypeScript (strict)
Runtime performance	Baseline	Identical	Identical
Build step	None	~2s (esbuild strips types)	~2s (same)
AI assistant quality	Low — no type context	Medium — partial types	High — full type context
Null/undefined bugs caught	None at compile time	Partial (no strictNullChecks)	Most caught at editor time
Refactoring safety	Manual search-and-fix	Partial	Compiler guides every rename
LLM SDK compatibility	Types not inferred	Partial	Full type inference and checks

There’s one scenario where plain JavaScript still makes sense: very short-lived scripts, quick local automation, or one-off data migrations where you need output in the next ten minutes and will never touch the code again. For anything you’ll maintain or deploy, strict TypeScript pays for itself within the first refactor.

What should you know about TypeScript 7 and compilation speed?

The historic complaint about TypeScript was compilation speed. On large codebases, tsc --watch could add noticeable delay to every save. That’s gone in 2026. TypeScript 7, codenamed Corsa, rewrites the compiler in Go — bringing a 10x speed improvement over TypeScript 5. Even with strict: true and noUncheckedIndexedAccess, the full type-check pass on a large monorepo now completes in under a second.

Modern build tools already bypassed most of this by using esbuild or swc to strip types (near-instant) and only running tsc in CI for the full type check. With TypeScript 7, even that bottleneck is effectively gone. The compilation-speed argument against TypeScript is no longer valid in 2026.

• TypeScript hit #1 on GitHub in August 2025 with 2.63 million monthly contributors — driven by AI coding tools creating a self-reinforcing “convenience loop” between typed codebases and better AI suggestions.
• AI assistants catch 94% fewer type errors in TypeScript codebases because type signatures give them precise contracts to work from — making TypeScript the safest foundation for AI-assisted development.
• Always enable strict: true in tsconfig.json and add noUncheckedIndexedAccess separately — these two settings together catch the vast majority of production-impacting bugs.
• JSON.parse() and fetch().json() return any even in strict mode — always validate external data shapes with a runtime library like Zod before passing it into your typed application code.
• TypeScript 7 (Corsa) removes the last major objection to TypeScript — a Go-based rewrite delivers 10x faster type-checking, making strict mode essentially free from a performance standpoint.
• For module resolution, use "bundler" for Vite/Next.js projects and "NodeNext" for Node.js — the wrong choice causes cryptic import errors that waste hours of debugging.

Frequently Asked Questions

Why did TypeScript become the #1 language on GitHub in 2025?

TypeScript overtook Python and JavaScript in August 2025 by reaching 2.63 million monthly contributors — a 66% year-over-year jump. The main drivers were AI coding tools preferring typed codebases, major frameworks defaulting to TypeScript, and a compounding convenience loop where more TypeScript usage generates better AI training data.

Does TypeScript slow down your application at runtime?

No. TypeScript compiles to plain JavaScript — the browser or Node.js runs the same code either way. There is zero runtime overhead. The only cost is a build step, and modern tools like esbuild, Vite, and Bun make that near-instant by stripping types without running full type-checking.

Should I enable strict mode in tsconfig.json?

Yes, always. Setting strict: true turns on eight compiler flags at once including strictNullChecks, noImplicitAny, and strictFunctionTypes. Non-strict TypeScript misses entire categories of null-pointer bugs and lets any types silently spread through your codebase. For new projects, enable strict from day one — retrofitting it later is painful.

What is the TypeScript noUncheckedIndexedAccess flag and why does it matter?

noUncheckedIndexedAccess makes array and object index access return T | undefined instead of T, forcing you to handle the case where an index does not exist. It is not included in strict: true — you have to opt in separately. This flag catches a common class of runtime crashes that strict mode alone will not prevent.

What is the biggest TypeScript gotcha in production code?

JSON.parse() and fetch().json() return type any even in full strict mode, meaning TypeScript cannot check any of the fields you access on parsed data. The fix is to validate the shape at runtime using a library like Zod and infer the TypeScript type from the schema — that way you get both runtime safety and static type safety.

Why do AI coding assistants work better with TypeScript?

AI assistants like Copilot and Cursor read your type signatures to generate suggestions. Explicit types act as inline documentation the AI can use to understand what a function expects and returns. A 2025 study found 94% of LLM compilation errors were type-check failures, so TypeScript catches AI mistakes before they reach production.

TypeScript’s rise to the top of GitHub isn’t a trend you wait out — it’s a structural shift driven by two compounding forces: AI tooling that works better with types, and a developer ecosystem that now defaults to TypeScript from project zero. The thing most teams still get wrong: they enable TypeScript but skip noUncheckedIndexedAccess and leave JSON.parse() results typed as any. Fix those two gaps and you’ll catch the majority of bugs that would otherwise only surface in production. Drop a comment below or subscribe to NexGismo for weekly posts like this — we cover the practical, production-focused side of modern web development every week.