The Story of How Dependabot's Major Version Bumps Broke Due to Ecosystem Unreadiness — The Traps of ESLint 10 and TypeScript 7

The Story of How Dependabot's Major Version Bumps Broke Due to Ecosystem Unreadiness — The Traps of ESLint 10 and TypeScript 7

Dependabot proposed major bumps for ESLint 9→10 and TypeScript 6→7, which broke CI. The cause was downstream plugins and tools not yet supporting the new versions. Here I summarize the process from investigation through to addressing the issue with ignore rules in dependabot.yml.
2026.07.21

This page has been translated by machine translation. View original

Introduction

Are you auto-merging major version bumps proposed by Dependabot?

In one project, Dependabot proposed a bump of eslint 9 → 10. We had it configured to auto-merge if CI passed, but sure enough, CI failed. Upon investigation, we encountered a pattern that's all too common with Dependabot: downstream plugins hadn't yet caught up, not the eslint core itself.

At the same time, a typescript 6 → 7 bump had also come in, and it was broken for the same reason.

This article summarizes the process from investigation to resolution, along with how to safely manage major bumps with Dependabot.

dependabot-major-bump-ecosystem-lag-dependency-chain

What Broke with ESLint 10

The Error

The following error occurred in the lint step of CI:

TypeError: contextOrFilename.getFilename is not a function

Cause: Breaking API Changes in ESLint 10

In ESLint 10 (released February 2026), methods such as context.getFilename(), context.getCwd(), and context.getSourceCode() were removed and replaced with property accessors (like context.filename).

This change had been signaled with deprecation warnings since ESLint 9, but whether plugins actually update to reflect this is a separate matter.

eslint-plugin-react Was Not Compatible

eslint-plugin-react@7.37.5 (the latest version on npm) internally calls context.getFilename(). A fix PR exists, but as of July 2026, it has not yet been merged or released.

Item Status
eslint-plugin-react latest version 7.37.5 (released over a year ago)
ESLint 10 compatibility issue #3977 — Open
Fix PR #3979 — Not merged
eslint-config-next compatibility vercel/next.js#91702 — Open

Since eslint-config-next depends on eslint-plugin-react, ESLint 10 cannot be used in Next.js projects until the upstream plugin catches up.

What Broke with TypeScript 7

Right after dealing with ESLint 10, I noticed that the typescript 6 → 7 Dependabot PR had also caused CI to fail.

TypeScript 6 was the last JavaScript-based release, and TypeScript 7 is a new compiler rewritten in Go. The version numbers are sequential, but internally they are completely different things.

Error 1: Next.js Build

It looks like you're trying to use TypeScript but do not have the required package(s) installed.

Despite TypeScript 7 being installed, Next.js was unable to detect it.

Error 2: ESLint

TypeError: Cannot read properties of undefined (reading 'Cjs')
    at @typescript-eslint/typescript-estree@8.63.0_typescript@7.0.2

typescript-eslint crashed while trying to access TypeScript 7's API.

Cause: TypeScript 7 Has No Programmatic API

TypeScript 7 is a new compiler rewritten in Go and does not include the traditional Node.js-oriented programmatic API. The API is expected to be provided in TypeScript 7.1.

Item Status
typescript-eslint compatibility issue #12518 — "not planned" (waiting for TS 7.1)
Interim workaround Using @typescript/typescript6 compatibility package to run TS 6 in parallel for ESLint
TS 7.1 release estimate TBD

Resolution: ignore Rules in dependabot.yml

Until the ecosystem catches up, we configured Dependabot to stop proposing major bumps.

dependabot.yml
updates:
  - package-ecosystem: "npm"
    directory: "/frontend"
    schedule:
      interval: "weekly"
    ignore:
      # eslint 10 breaks eslint-plugin-react (getFilename removed).
      # Unblock once eslint-config-next supports eslint 10.
      # Tracking: https://github.com/vercel/next.js/issues/91702
      - dependency-name: "eslint"
        update-types: ["version-update:semver-major"]
      # TS 7 has no programmatic API; typescript-eslint and Next.js don't support it.
      # Unblock once typescript-eslint ships TS 7 support (expected after TS 7.1).
      # Tracking: https://github.com/typescript-eslint/typescript-eslint/issues/12518
      - dependency-name: "typescript"
        update-types: ["version-update:semver-major"]

Key points:

  • update-types: ["version-update:semver-major"] blocks only major bumps. Minor and patch updates will still be proposed
  • Include Tracking issue URLs in comments to make it clear when the block should be lifted
  • cooldown.semver-major-days only reduces frequency and cannot stop proposals entirely. Use ignore to block them completely

Investigation Workflow

Here is a summary of the process from investigation to resolution in this case. Use this as a reference if you encounter a similar issue.

dependabot-major-bump-ecosystem-lag-workflow

1. Identify the failing area from CI logs

gh run view <run-id> --log-failed

Use the error message to identify which package is broken.

2. Check upstream issues/PRs

  • Search the package's GitHub repository for compatibility status
  • Check the supported range in peerDependencies

3. Assess the ecosystem's readiness

Questions to ask:

  • Does a fix PR exist? Has it been merged?
  • Has it been released?
  • Is the entire dependency chain compatible? (e.g., eslint-config-next → eslint-plugin-react → eslint)

4. Add ignore rules to dependabot.yml

If upstream is not yet compatible, set up an ignore rule with a link to the tracking issue.

Summary

  • For major version bumps, you need to verify not just the target package but the compatibility of the entire ecosystem
  • It is not uncommon for ecosystems to take months or even over a year to catch up after ESLint 10 and TypeScript 7 releases (the ESLint 9 flat config migration also took over a year)
  • By specifying update-types: ["version-update:semver-major"] in Dependabot's ignore rules, you can block only major bumps
  • Leave comments in ignore rules with Tracking issue URLs. This prevents forgetting to remove the block and helps team members understand the background

Share this article