chore(deps-dev): bump @typescript-eslint/parser from 5.62.0 to 8.59.0#11643
chore(deps-dev): bump @typescript-eslint/parser from 5.62.0 to 8.59.0#11643dependabot[bot] wants to merge 1 commit intodevelopfrom
Conversation
botwoo
left a comment
There was a problem hiding this comment.
Hey @dependabot[bot] — thanks for keeping dependencies current. This bump targets @typescript-eslint/parser, jumping three major versions from 5.62.0 to 8.59.0. The new version brings TypeScript 6 support and several parser improvements, which is great to have on the roadmap.
- The bump itself is clean — all new transitive dependencies (
tinyglobby,fdir,ts-api-utils,@typescript-eslint/project-service,@typescript-eslint/tsconfig-utils) are legitimate packages from the official typescript-eslint monorepo and npm registry. - This is a dev-only dependency, so there's zero production risk to the plugin bundle or payment flows.
- Jest tests and TypeScript compilation (
tsc --noEmit) are completely unaffected since they don't use the ESLint parser. - One blocking concern:
@typescript-eslint/eslint-pluginstays at 5.62.0 while the parser jumps to 8.59.0 — these are designed to run at the same major version, and the plugin's peer dependency explicitly requires^5.0.0.
Detailed findings
All TypeScript linting rules affected by AST mismatch
- File:
.eslintrc:122 - Severity: important
The TypeScript override block (lines 122–158) sets "parser": "@typescript-eslint/parser" (now v8) and extends "plugin:@typescript-eslint/recommended" (from the v5 plugin). This means every .ts and .tsx file gets parsed with v8 AST but validated by v5 rules.
Rules configured here — @typescript-eslint/naming-convention, @typescript-eslint/no-shadow, @typescript-eslint/no-use-before-define, @typescript-eslint/no-unused-vars — may silently misinterpret AST nodes whose structure changed between v5 and v8.
Could we run npm run lint:js on a test branch with these versions to see if any rules actually break? That would help scope the upgrade work if we decide to go the v8 route.
legacy-peer-deps masks the incompatibility during install
- File:
.npmrc:1 - Severity: suggestion
The .npmrc setting legacy-peer-deps=true allows npm ci and npm install to succeed despite the peer dependency violation. This means CI won't catch the mismatch at install time — the incompatibility only surfaces at ESLint runtime, making it harder to detect.
This is worth noting because the install step passing in CI might give false confidence that the bump is safe.
Automated review by Botwoo
| "@types/wordpress__data-controls": "2.2.0", | ||
| "@typescript-eslint/eslint-plugin": "5.62.0", | ||
| "@typescript-eslint/parser": "5.62.0", | ||
| "@typescript-eslint/parser": "8.59.0", |
There was a problem hiding this comment.
[CRITICAL] The @typescript-eslint/parser is being bumped to 8.59.0, but @typescript-eslint/eslint-plugin remains at 5.62.0 (line 134). The plugin's peerDependencies require @typescript-eslint/parser: ^5.0.0 — the v8 parser violates this constraint.
These two packages are from the same monorepo and share internal type definitions (@typescript-eslint/types, @typescript-eslint/scope-manager, @typescript-eslint/typescript-estree). Parser v8 produces AST nodes in a format that the v5 plugin's rules don't expect, which can cause silent false negatives, unexpected errors, or rule crashes when linting TypeScript files.
What if we either bump both packages to v8 together (reviewing the v6/v7/v8 migration guides for breaking rule changes), or close this PR and keep them aligned at v5?
|
Dependabot couldn't access the repository. Because of this, Dependabot cannot update this pull request. |
237a04d to
5b41e60
Compare
|
Hey @dependabot[bot] — thanks for keeping dependencies up to date. The parser bump itself targets a well-maintained package with solid release notes, and the lockfile resolution correctly nests the old v5 parser under
Automated review by Botwoo |
Bumps [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/parser) from 5.62.0 to 8.59.0. - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.59.0/packages/parser) --- updated-dependencies: - dependency-name: "@typescript-eslint/parser" dependency-version: 8.59.0 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
5b41e60 to
a06402c
Compare
botwoo
left a comment
There was a problem hiding this comment.
Hey @dependabot[bot] — thanks for keeping dependencies up to date. The parser bump itself targets a well-maintained package with clean transitive deps, and the lockfile correctly nests v5 copies for downstream eslint plugins so they stay isolated.
- Clean dependency tree: all new transitive packages (tinyglobby, fdir, ts-api-utils, etc.) are well-known, MIT-licensed, and resolve from the official npm registry
- Nested resolution is correct: @woocommerce/eslint-plugin and @wordpress/eslint-plugin each get their own pinned v5.62.0 parser copy, so they won't break
- Dev-only change: no production code, bundle size, or runtime behavior is affected
- One blocking issue: @typescript-eslint/parser v8 and @typescript-eslint/eslint-plugin v5 are incompatible — mixing major versions will break ESLint on TypeScript files
Detailed findings
ESLint rule configuration may need updates for v8
- File:
.eslintrc:126 - Severity: important
If upgrading the plugin to v8 to match: several @typescript-eslint rules were renamed or had defaults changed across the v6/v7/v8 releases. For example, @typescript-eslint/no-unused-vars and @typescript-eslint/naming-convention (used in this config at lines 94 and 135-147) may have different option shapes. Could we review the typescript-eslint migration guides and validate the .eslintrc rules still work with v8 before merging?
Automated review by Botwoo
| "@types/wordpress__data-controls": "2.2.0", | ||
| "@typescript-eslint/eslint-plugin": "5.62.0", | ||
| "@typescript-eslint/parser": "5.62.0", | ||
| "@typescript-eslint/parser": "8.59.0", |
There was a problem hiding this comment.
[CRITICAL] The @typescript-eslint/parser is bumped to 8.59.0 (line 135) while @typescript-eslint/eslint-plugin remains at 5.62.0 (line 134). The typescript-eslint project explicitly requires all @typescript-eslint/* packages to share the same major version — mixing them is unsupported and will produce ESLint errors or silently wrong lint results.
The .eslintrc TypeScript override uses both together: "parser": "@typescript-eslint/parser" (line 124) and "plugin:@typescript-eslint/recommended" (line 128).
What if we either:
- Bump
@typescript-eslint/eslint-pluginto 8.x in the same PR, or - Hold this PR until a coordinated upgrade of both packages can be done together?
Bumps @typescript-eslint/parser from 5.62.0 to 8.59.0.
Release notes
Sourced from
@typescript-eslint/parser's releases.... (truncated)
Changelog
Sourced from
@typescript-eslint/parser's changelog.... (truncated)
Commits
ea9ae4fchore(release): publish 8.59.090c2803chore(release): publish 8.58.2be6b49afix: remove tsbuildinfo cache file from published packages (#12187)5311ed3chore(release): publish 8.58.14933417chore(release): publish 8.58.08cde2d0feat: support TypeScript 6 (#12124)be4d54dchore(release): publish 8.57.2c7c38aachore(release): publish 8.57.12c6aeeechore(release): publish 8.57.0f696dadchore: use pnpm catalog (#12047)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for
@typescript-eslint/parsersince your current version.