Introduction

GraphQL Code Generator is a powerful tool that streamlines the integration between GraphQL schemas and TypeScript types. However, when it fails, the debugging experience can quickly spiral into frustration — especially in monorepo setups using Yarn workspaces.

This post documents a deceptively simple issue: GraphQL Codegen failing with misleading error messages, when the true culprit was a missing peer dependency — @babel/runtime.

The Symptom: Misleading Failure Output

After setting up GraphQL Codegen in a Yarn workspace project, you might run the familiar command:

yarn graphql-codegen -v

Only to be met with this confusing output:

[STARTED] Parse Configuration[SUCCESS] Parse Configuration[STARTED] Generate outputs[STARTED] Generate to gql/index.ts[STARTED] Load GraphQL schemas[SUCCESS] Load GraphQL schemas[STARTED] Load GraphQL documents[SUCCESS] Load GraphQL documents[STARTED] Generate[FAILED][FAILED]         Unable to find template plugin matching 'typescript-react-apollo'[FAILED]         Install one of the following packages:...[FAILED]         - @graphql-codegen/typescript-react-apollo...

The message suggests a missing plugin — but what if it is installed?

The Wrong Assumptions

This scenario typically leads developers down the wrong path, especially in a Yarn workspace setup:

• Hoisting issues?
  Maybe the plugin was installed in the root instead of the package?
• pluginSearchDirs?
  You might tweak the config to manually set plugin resolution paths.
• Require resolution checks?
  Perhaps running require.resolve() confirms the plugin exists.
• Git bisects and diff reviews?
  Comparing commits where Codegen worked fine versus failing builds.

All signs point to the plugin being available, and yet Codegen continues to fail with the same misleading error.

The Real Culprit: Missing @babel/runtime

Eventually, the truth reveals itself: the actual issue isn't the plugin at all.

It’s the absence of @babel/runtime.

GraphQL Code Generator and several of its plugins are compiled with Babel. They rely on runtime helpers that are expected to be available at runtime via the @babel/runtime package.

However, if that package is missing, the system doesn’t crash gracefully. Instead, the error manifests upstream — such as Codegen claiming it can’t find the plugin.

The Fix

Simply install the missing dependency:

yarn add -D @babel/runtime

And everything starts working:

• Types are generated.
• Apollo hooks are scaffolded.
• Codegen stops complaining.

Lessons Learned

This debugging journey highlights several important takeaways:

1. Error Messages Can Be Deceptive

Don’t take them at face value. A failure about one thing may actually be triggered by something entirely different.

2. Peer Dependencies Are Fragile

@babel/runtime is a peer dependency for many Babel-based packages, but it’s not auto-installed. When omitted, it fails silently — or worse, misleadingly.

3. Yarn Workspaces Aren’t Always the Problem

When working in monorepos, it’s easy to assume workspace-related bugs. But sometimes, the issue is far simpler.

Takeaway

If you see plugin errors like:

Unable to find template plugin matching 'typescript-react-apollo'

And you're absolutely sure the plugin is installed — take a step back. The issue may not be Codegen or your Yarn workspace setup.

Try this first:

yarn add -D @babel/runtime

A single missing package might be standing between you and hours of your life.

Bonus Tip: Consider Automating Dependency Checks

For monorepos, using a tool like knip or defining a minimal required dependency list in each workspace’s package.json can prevent similar issues in the future.