How to Fix: Problem with apollographql using turbopack – Unexpected error processing request: TypeError: module.require is not a function

Turbopack is choking on apollographql because that package assumes a CommonJS runtime and tries to call module.require(), but the module object exposed during Turbopack bundling does not implement that API. The result is the runtime crash: TypeError: module.require is not a function.

Understanding the Root Cause

This issue appears when a Next.js 15 app is started with Turbopack and a dependency in the GraphQL stack pulls in the apollographql package in a way that expects legacy Node.js module behavior.

The key problem is not GraphQL itself. The problem is the interaction between:

• Turbopack’s module system
• CommonJS-specific package code
• apollo-related transitive dependencies that still rely on module.require

In classic Node.js CommonJS execution, module.require() is available as part of the module wrapper. Some older libraries use it directly instead of the normal require() function. Turbopack, however, transforms and evaluates modules through its own runtime layer. In that environment, the exported module object is not guaranteed to behave like native Node’s internal module instance.

That means code such as:

module.require('some-package')

can fail even though the same code may work in:

• plain Node.js
• Webpack-based Next.js builds
• older dev setups without Turbopack

So the real root cause is a compatibility gap between Turbopack and a dependency that assumes Node-specific CommonJS internals.

If you inspect the reproduction linked in the issue, the crash happens as soon as the page loads under Turbopack, which confirms this is a bundling/runtime compatibility problem rather than a GraphQL query error or application logic bug.

Step-by-Step Solution

The safest fix is to remove the incompatible package path from your app and use the modern Apollo packages that are compatible with the current Next.js ecosystem.

1. Identify where apollographql enters the dependency graph

Run one of the following commands in your project root:

npm ls apollographql

pnpm why apollographql

yarn why apollographql

If the package is installed directly, remove it. If it is transitive, trace which Apollo-related package is pulling it in.

2. Remove outdated or incompatible Apollo packages

Uninstall the problematic package set:

npm remove apollographql

If your app is using older Apollo helpers, remove them too and replace them with the current supported client packages.

3. Install the modern Apollo client stack

npm install @apollo/client graphql

If you are integrating Apollo with the Next.js App Router, also install the official Next integration package if your setup needs it:

npm install @apollo/client-integration-nextjs

4. Replace old imports

If your code imports anything from deprecated Apollo packages, switch to modern imports.

Example Apollo client setup:

import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client';

Example client factory:

import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client';

export function makeApolloClient() {
  return new ApolloClient({
    link: new HttpLink({
      uri: 'https://example.com/graphql'
    }),
    cache: new InMemoryCache()
  });
}

5. If you need an immediate workaround, disable Turbopack for development

If upgrading dependencies is not possible right away, use the standard dev server instead of Turbopack.

next dev

Or update your script in package.json:

{
  "scripts": {
    "dev": "next dev"
  }
}

This does not solve the underlying incompatibility, but it restores local development while you migrate away from the package path that depends on module.require.

6. Clear caches after dependency changes

After replacing packages, remove build artifacts and reinstall dependencies:

rm -rf .next node_modules package-lock.json

npm install

npm run dev

If you use pnpm or yarn, remove the appropriate lockfile instead.

7. Verify the fix

Start the project again with Turbopack:

next dev --turbo

If the incompatible package is no longer part of the dependency graph, the page should render without the module.require crash.

Recommended stable setup

A minimal dependency set for this use case should usually look like this:

{
  "dependencies": {
    "next": "15.x",
    "react": "19.x",
    "react-dom": "19.x",
    "graphql": "^16.x",
    "@apollo/client": "^3.x"
  }
}

If you need server/client boundary helpers for the App Router, add the official integration package rather than older community workarounds.

Common Edge Cases

• Transitive dependency still present: You may remove apollographql directly, but another package can reinstall it indirectly. Always verify with npm ls or pnpm why.
• Mixed Apollo generations: Combining old Apollo utilities with @apollo/client can keep the incompatible code path alive.
• Lockfile drift: Your node_modules may not reflect package.json after partial upgrades. Delete the lockfile and reinstall if needed.
• App Router vs Pages Router confusion: Some examples online target older Next.js routing models. Using the wrong integration pattern can produce misleading errors that look unrelated.
• SSR-only code imported into client components: If Apollo setup includes server-only utilities and they leak into the browser bundle, Turbopack may surface additional module runtime errors.
• Different behavior between Webpack and Turbopack: A package working under Webpack does not guarantee Turbopack compatibility, especially if it relies on undocumented Node internals.

FAQ

Is this a bug in GraphQL itself?

No. GraphQL is not the cause. The failure comes from a package in the Apollo dependency chain that expects Node CommonJS internals unavailable in Turbopack’s runtime.

Why does the project work without Turbopack?

Webpack and plain Node-based execution often tolerate older CommonJS patterns better. Turbopack is stricter here, so the incompatible module.require() usage becomes visible.

Can I patch the package instead of removing it?

Yes, but it is usually a temporary fix. You could patch the offending dependency to replace module.require(…) with require(…) or a supported import pattern, but long term the better solution is to move to the current Apollo packages and avoid legacy dependency paths.

For reference, use the reproduction repository linked in the issue to compare behavior before and after dependency cleanup: issue reproduction repo.