Fix “Installing TypeScript As It Was Not Found While Loading next.config.ts”

I hit this one inside a Docker container, at three in the morning, watching a deploy log scroll past. The line was short and easy to miss:

⚠ Installing TypeScript as it was not found while loading "next.config.ts".

⚠ Installing TypeScript as it was not found while loading "next.config.ts".

You will learn what causes the “installing TypeScript as it was not found while loading next.config.ts” warning, and four ways to fix it depending on where you’re seeing it.

What this post covers: Next.js 15 and 16, the App Router, and both local and production setups. I’ll show the Docker and CI case too, because that’s where this warning actually costs you something.

Before you copy a fix. If you’re only seeing this once on your own machine, it’s harmless. Next.js installs TypeScript and moves on. If you’re seeing it in production or in a container, don’t just install TypeScript and walk away. The warning is telling you something about your deploy that’s worth fixing properly.

What does this warning actually mean?

Your project has a next.config.ts file. That file is TypeScript, so something has to compile it before Next.js can read your config.

Next.js looks for the typescript package in your node_modules. When it doesn’t find it, it installs it for you, right there at startup, and prints that warning.

So the message is not an error. It’s Next.js saying: “I needed a package, you didn’t have it, I fetched it.”

For example, the three places you’ll see it:

1. Local dev. You added a next.config.ts to a JavaScript project. Harmless, happens once.
2. CI or Docker. Your production install stripped dev dependencies. This one matters.
3. A monorepo. TypeScript is installed at the root but not in the app package.

Why it’s a real problem in production

On your laptop this costs you two seconds. In a container it costs you more than that.

For example, you can see:

1. Your app makes a network request to npm on every cold start.
2. If the container has no outbound network access, startup fails instead of just warning.
3. If the filesystem is read-only, the install can’t write and you get an error you didn’t expect.
4. Your package.json and lockfile can get modified inside a running production container.

None of that is what you want from next start. So the fix depends on which of the three cases you’re in.

Step 1: Find out where TypeScript actually is

Don’t guess. Ask npm.

npm ls typescript

You’ll get one of three answers:

# Not installed at all
└── (empty)

# Installed as a dev dependency
└── typescript@5.9.2

# Installed somewhere up the tree in a monorepo
└─┬ my-app
  └── typescript@5.9.2 deduped

# Not installed at all
└── (empty)

# Installed as a dev dependency
└── typescript@5.9.2

# Installed somewhere up the tree in a monorepo
└─┬ my-app
  └── typescript@5.9.2 deduped

Here’s what I look at. If it prints empty, TypeScript was never installed. If it prints a version locally but the warning still appears in your Docker build, then your production install step is removing it. That difference decides which fix you use next.

Step 2: Install TypeScript as a dev dependency

This is the fix for the local case, and it’s one line.

npm install -D typescript @types/node @types/react

npm install -D typescript @types/node @types/react

For other package managers:

pnpm add -D typescript @types/node @types/react
yarn add -D typescript @types/node @types/react
bun add -d typescript @types/node @types/react

pnpm add -D typescript @types/node @types/react
yarn add -D typescript @types/node @types/react
bun add -d typescript @types/node @types/react

I added @types/node and @types/react alongside it because your next.config.ts imports NextConfig from next, and your editor needs those types to stop complaining. Restart the dev server after installing and the warning is gone.

If your config file doesn’t have types yet, it should look like this:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  /* your options here */
}

export default nextConfig

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  /* your options here */
}

export default nextConfig

Step 3: Stop your production install from removing TypeScript

This is the Docker and CI case, and it’s the one people actually search for.

Any of these commands will strip typescript out, because it lives in devDependencies:

npm ci --omit=dev
npm prune --production
NODE_ENV=production npm install

npm ci --omit=dev
npm prune --production
NODE_ENV=production npm install

Then next start boots, finds no TypeScript, and reinstalls it inside your running container.

You have two ways out. The blunt one is to move TypeScript into regular dependencies:

{
  "dependencies": {
    "next": "^16.0.0",
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "typescript": "^5.9.2" //moved out of devDependencies
  }
}

{
  "dependencies": {
    "next": "^16.0.0",
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "typescript": "^5.9.2" //moved out of devDependencies
  }
}

That works, and I’ve shipped it. But it means a TypeScript compiler rides along in your production image forever, and the whole point of pruning was to avoid that.

The better option is to use a standalone build. Set it in your config:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  output: 'standalone', //bundles a minimal server into .next/standalone
}

export default nextConfig

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  output: 'standalone', //bundles a minimal server into .next/standalone
}

export default nextConfig

With standalone output, your config is resolved at build time and bundled into the generated server. Your runtime stage copies .next/standalone and runs node server.js instead of next start, so nothing needs to read next.config.ts at boot. See the Next.js output docs for the exact files to copy in your Dockerfile.

Step 4: Let Node.js load next.config.ts natively

This is my favourite fix, and it needs no extra package at all.

Node.js can strip TypeScript types on its own now. Next.js checks for it and skips the typescript package entirely when it’s available.

node -v
# v22.18.0 or higher

node -v
# v22.18.0 or higher

On Node 22.18 and later, native TypeScript support is on by default, so this works with no flags. On Node 22.10 through 22.17, you opt in:

NODE_OPTIONS=--experimental-transform-types next start

NODE_OPTIONS=--experimental-transform-types next start

Next.js detects this through process.features.typescript. When it’s there, next.config.ts gets loaded natively, and you also get ESM syntax, top-level await, and dynamic import() inside your config file.

One detail from the docs worth knowing. If your project is CommonJS, meaning package.json has no "type": "module", use a next.config.mts file instead:

// next.config.mts
import type { NextConfig } from 'next'

const flags = await import('./flags.js').then((m) => m.default ?? m) //top-level await works here

const nextConfig: NextConfig = {
  typedRoutes: Boolean(flags?.typedRoutes),
}

export default nextConfig

// next.config.mts
import type { NextConfig } from 'next'

const flags = await import('./flags.js').then((m) => m.default ?? m) //top-level await works here

const nextConfig: NextConfig = {
  typedRoutes: Boolean(flags?.typedRoutes),
}

export default nextConfig

The .mts extension tells Node the file is ESM, so it doesn’t parse it twice.

Step 5: The monorepo case

In a pnpm or npm workspace, TypeScript is often installed once at the root. Next.js resolves from the app package, and with pnpm’s strict node_modules layout, it doesn’t always find it there.

Install it in the package that owns the next.config.ts, not just at the root:

pnpm add -D typescript --filter my-app

pnpm add -D typescript --filter my-app

I ran into this after switching a project to pnpm. Everything built fine, the warning only appeared for one app in the workspace, and the reason was that the root install had never been linked into that package.

Which fix should you use?

There are four, and they don’t compete. Pick by where the warning shows up.

1. Local dev only. Install TypeScript as a dev dependency. Step 2. Done in ten seconds.
2. Docker or CI with pruned dependencies. Use output: 'standalone' and stop running next start in your runtime image. Step 3.
3. You control the Node version and want no extra packages. Use Node 22.18+ and let it load next.config.ts natively. Step 4.
4. Monorepo. Install TypeScript in the app package itself. Step 5.

If you want the simplest thing that also removes the problem from production, I’d go with step 4 plus step 2. Node handles the config file, TypeScript stays a dev dependency where it belongs, and your production image never needs a compiler.

Moving TypeScript into dependencies is the fix I’d pick last. It works, but it makes your production image bigger to solve a config parsing problem, and it hides the deploy issue instead of fixing it.

There are more Next.js posts covering config, deploys, and metadata on my blog if you want to keep going.

Wrapping up

“Installing TypeScript as it was not found while loading next.config.ts” is a warning, not a crash. It means Next.js needed the TypeScript package to read your config file and had to fetch it itself.

On your machine, install it as a dev dependency and forget about it. In a container, treat it as a signal that your runtime is doing work that belongs in your build.

These steps are written for Next.js 16 and work the same on Next.js 15, where next.config.ts support was first added. The Node native TypeScript part needs Node 22.10 or later.

Thanks for reading. If your setup is different and the warning still won’t go away, leave a comment with your Dockerfile and I’ll take a look.