The Dependabot PR that broke the build, and the one that broke accessibility

Two Dependabot PRs were sitting open on this site. One was a straightforward security patch. The other bundled three dependency bumps together, and its build was red.

The easy instinct is to click “recreate” on the failing PR and hope a rebase fixes it, or force-merge and see what breaks in production. Neither felt right, so I cloned the branch into a scratch directory and ran the same checks the Cloudflare build actually runs - the checks that turned out not to cover everything, but do cover this.

The first bump: TypeScript 7 breaks astro check

The grouped PR bumped typescript from 6.0.3 to 7.0.2 alongside two other packages. npm run check failed immediately: the TypeScript module loaded doesn’t expose the programmatic API astro check relies on, because TypeScript 7’s native compiler doesn’t ship it yet.

That’s a known upstream gap, nothing to do with my config. Pinning typescript back to ~6.0.3 and re-running gave a clean zero errors, zero warnings.

The second bump: a new parser quietly drops attributes

With TypeScript pinned back, I re-ran the full local gate against the other two bumps. npm run lint:ci failed with a jsx-a11y/no-noninteractive-tabindex error on a <pre> tag carrying a deliberate role="region" and tabindex="0" for keyboard-scrollable content - added in an earlier accessibility fix.

That pattern is a real, valid WCAG technique. So why was it suddenly flagged?

eslint-plugin-astro 3.0 switched to a new Rust-based parser. I asked ESLint for its JSON output and read the source snippet it had actually parsed. The role="region" and aria-label={...} attributes were missing from the source ESLint saw, even though they’re right there in the file. The new parser was dropping them before handing the tag to jsx-a11y, so the rule had no way to know the element was an accessible landmark region.

A real regression in the new major version, not a problem with my markup. Worth noticing that the failure looked exactly like my own code being wrong, which is the same trap a CSP error on a line I’d just edited set for me a week earlier.

What actually shipped

Of the three bumped dependencies, only start-server-and-test (the harness behind the accessibility suite) turned out to be safe. I applied that one by hand, ran the full local gate including all 39 accessibility pages, and merged it. The standalone security patch merged cleanly on its own. typescript and eslint-plugin-astro stay put until the upstream issues are fixed.

The real fix was the config

The root cause wasn’t either dependency. It was the Dependabot config, which grouped every npm update into one bucket regardless of patch or major. One breaking major release could block two harmless ones from ever merging, since they all lived in the same PR.

I scoped the group to minor and patch updates only. Major bumps now show up as their own individual PRs. Small config change, but a breaking major can’t hold safe updates hostage again.

The typescript major bump will keep reappearing on its own weekly PR until Astro supports TypeScript 7’s native compiler. I’m leaving it to recur rather than silencing it. A red PR that shows up every week is a better reminder to check whether it’s been fixed than a config entry I’d have to remember to remove later.