chore(deps-dev): bump @eslint/js from 9.29.0 to 10.0.1 - #530
chore(deps-dev): bump @eslint/js from 9.29.0 to 10.0.1#530dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
changed the title
5b291a6 to
984c7f3
Compare
dependabot
Bot
changed the title
984c7f3 to
ee0727c
Compare
![minsky-reviewer[bot]](https://avatars.githubusercontent.com/u/52695?s=60&v=4){kind=small}
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Findings
-
[BLOCKING] package.json:54-60 — Bumping @eslint/js to 10.0.1 introduces a new peerDependency on eslint (upstream commit 1f66734 in the release notes you cited). This PR only changes @eslint/js (package.json devDependencies) and does not add or adjust a direct eslint dependency. If eslint is not already declared at a compatible version, installs under pnpm or Yarn PnP can error or warn, and CI lint may break. Action: explicitly ensure eslint is present in devDependencies with a compatible version for @eslint/js 10 (and update the lockfile). If it already exists, please point to the current version in package.json to confirm compatibility.
-
[NON-BLOCKING] package.json (engines)/CI Node version — Upstream now requires Node.js ^20.19.0 || ^22.13.0 || >=24 (release notes commit c6358c3). This PR does not adjust any engines field in package.json or CI Node versions. If your project/CI still runs Node < 20.19 (e.g., Node 18), linting will fail at install or runtime. Please verify CI workflows and package.json engines (if present) are aligned with this requirement.
-
[NON-BLOCKING] Lint behavior change risk — @eslint/js v10 updates eslint:recommended (release notes commit 454a292). If your config extends eslint:recommended, this can introduce new lint failures. The PR doesn’t include any config updates or baseline changes. Please run lint across the repo and include any necessary rule/config updates in this PR or follow up with a dedicated change.
-
[NON-BLOCKING] Lockfile not updated — The diff only shows package.json changes; there are no changes to any lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lockb). If this repo commits a lockfile, please regenerate it to keep CI reproducible.
Spec verification
- No task spec provided. N/A.
Documentation impact
- Yes. Update contributor/setup docs to reflect the new minimum Node version requirement (Node ^20.19.0 || ^22.13.0 || >=24) and note potential lint behavior changes from the updated eslint:recommended preset. If the project commits to a specific Node version in tooling (e.g., .nvmrc, Volta, or engines), ensure those are aligned and documented.
Event: REQUEST_CHANGES
ee0727c to
bb7df34
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Findings
-
[NON-BLOCKING] package.json: devDependencies — @eslint/js 10.0.1 now declares a peerDependency on eslint (see upstream commit 1f66734 referenced in the PR description). Your package.json still pins eslint at ^9.29.0:
- File: package.json, devDependencies.eslint: "^9.29.0"
- Risk: The new @eslint/js 10.x recommended config references rule sets aligned to newer ESLint 9.39+ releases. Running ESLint 9.29.0 with @eslint/js 10.0.1 can lead to “Definition for rule '…' was not found” or schema mismatches, and can also produce peer dependency resolution warnings/errors under stricter installers (pnpm/Yarn PnP).
- Evidence:
- package.json shows "@eslint/js": "10.0.1" and "eslint": "^9.29.0"
- eslint.config.js line 1:
import js from "@eslint/js";and later usesjs.configs.recommended, which in v10 tracks updated recommended rules that may require a newer eslint core.
- Ask: Upgrade devDependencies.eslint to a version compatible with @eslint/js 10.0.1 (e.g., >= 9.39.x per the upstream release notes) and update the lockfile.
-
[NON-BLOCKING] Lockfile not updated — The repo tracks a Bun lockfile (bun.lock). This PR changes package.json but does not include a corresponding bun.lock update.
- File: bun.lock (no change in diff; file exists in repo root)
- Risk: CI or subsequent installs may resolve different versions than what CI validated, creating non-reproducible builds. Given a new peer on eslint, the actual resolved graph matters.
- Ask: Run bun install and commit the updated bun.lock alongside the dependency bump.
-
[NON-BLOCKING] CI may fail lint due to the version skew
- Files:
- .github/workflows/ci.yml: “Lint (strict — fails on any warning)” runs
bun run lint:strict - eslint.config.js: uses
js.configs.recommendedfrom @eslint/js 10.0.1
- .github/workflows/ci.yml: “Lint (strict — fails on any warning)” runs
- Risk: If @eslint/js 10.0.1 expects rules not present in eslint 9.29.0, the lint step can error, failing CI. This is a practical break in the dev pipeline even if not user-facing behavior.
- Files:
-
[NON-BLOCKING] Node engines compatibility check
- Context: Release notes for @eslint/js 10 indicate Node.js requirement of ^20.19.0 || ^22.13.0 || >=24. Your package.json has no "engines" field, and CI uses Bun (oven-sh/setup-bun@v2) rather than Node.
- Files:
- package.json: no "engines" field
- .github/workflows/ci.yml: uses Bun 1.2.21
- Risk: While Bun runs eslint, installers can still evaluate Node engines for dependencies. Bun’s resolver may not enforce engines strictly, but this is worth confirming to avoid install-time warnings or future breakage if a Node runtime is introduced elsewhere in CI.
- Ask: Optionally document/confirm that Bun install won’t be blocked by engines for these packages, or specify a Node version for environments that do run eslint under Node.
Spec verification
- No explicit task spec provided. Treating intent as “bump @eslint/js from 9.29.0 to 10.0.1.”
- Ensure @eslint/js is upgraded: Met (package.json updated to 10.0.1)
- Ensure compatibility with new peerDependency on eslint: Not Met (eslint remains at ^9.29.0)
- Ensure lockfile/cached resolution aligns: Not Met (bun.lock not updated in PR)
- Confirm CI will pass with new combo: Not Met (version skew risk noted above)
Documentation impact
- Consider adding a short note in CONTRIBUTING.md or a dependency policy doc:
- @eslint/js 10.x requires a compatible eslint core (e.g., >= 9.39.x); keep these in sync.
- Note Node/Bun runtime expectations for linting to avoid engines confusion.
Event: COMMENT
Rationale: This PR is categorized as trivial/docs-only for severity calibration, so I’m flagging issues as non-blocking. However, the eslint peer version mismatch and missing lockfile update are likely to cause CI or local install/lint issues and should be addressed before merge.
bb7df34 to
38130b1
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Findings
-
[NON-BLOCKING] bun.lock:4 — Lockfile not updated to reflect the bump. In bun.lock, the root workspace devDependencies still resolve "@eslint/js": "9.29.0", and the packages map likewise pins @eslint/js@9.29.0, while package.json now requires "@eslint/js": "10.0.1". Evidence:
- bun.lock top-level devDependencies shows "@eslint/js": "9.29.0".
- bun.lock packages entry for "@eslint/js@9.29.0" exists.
- .github/workflows/ci.yml:27 runs bun install with --frozen-lockfile, which will fail when package.json and bun.lock disagree.
- File: .github/workflows/ci.yml:27
- File: bun.lock: lines near start (root devDependencies) and packages entry "@eslint/js@9.29.0"
Impact: CI will deterministically fail under --frozen-lockfile. Action: run bun install to regenerate bun.lock with @eslint/js 10.0.1 and commit the updated lockfile.
-
[NON-BLOCKING] package.json: devDependencies.eslint — Potential peer compatibility gap. Upstream added a peerDependency on eslint for @eslint/js v10 (see release notes commit 1f66734). This repo pins "eslint": "^9.29.0" alongside "@eslint/js": "10.0.1". While it may work, @eslint/js 10 recommended configs track newer ESLint 9.39+; older ESLint can surface “Definition for rule '…' was not found” or schema mismatches and produce peer warnings under stricter installers. Evidence:
- package.json devDependencies: "@eslint/js": "10.0.1", "eslint": "^9.29.0"
- eslint.config.js imports @eslint/js and uses js.configs.recommended (file: eslint.config.js:1, 21)
Suggestion: bump eslint to a recent compatible 9.39.x+ and update bun.lock, or document that 9.29.0 is intentionally supported and verified in CI.
-
[NON-BLOCKING] .github/workflows/ci.yml:20 — Node engine requirement heads-up. @eslint/js v10 notes a Node.js engines constraint (^20.19.0 || ^22.13.0 || >=24). CI runs tasks via Bun 1.2.21; if any developers or hooks run ESLint under Node, ensure local Node versions satisfy the requirement to avoid environment-specific breakage. Probably fine if everything runs under Bun, but worth acknowledging.
Spec verification
- No task spec provided. All criteria: N/A
Documentation impact
- No user-facing behavior change, but:
- Contributing/CI docs may benefit from a brief note: “If bumping dev tooling, regenerate and commit bun.lock (CI uses --frozen-lockfile).”
- If you decide to rely on Bun-only execution for linting, consider documenting the Node engine caveat for local devs.
Event: COMMENT
Rationale: This PR is a dev-dependency bump. Under the trivial/docs-only calibration, blocking is reserved for security, data-loss/correctness on user-facing behavior, scope creep, or legal issues. The most pressing issue here is the stale lockfile, which will break CI, but it does not fall into those categories; still, it should be fixed before merge.
38130b1 to
55f1e24
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
This dependency bump updates @eslint/js to 10.0.1 as intended, but the ecosystem around it is out of sync. bun.lock still resolves @eslint/js 9.29.0 while CI installs with --frozen-lockfile, so the pipeline will fail until the lockfile is regenerated and committed. @eslint/js v10 also adds a peerDependency on eslint; the repo still pins eslint ^9.29.0, which risks peer/version skew and potential lint errors with the updated recommended config. Finally, v10’s Node engines note may affect Node-based local workflows. Please regenerate bun.lock, upgrade eslint to a compatible version (e.g., >=9.39.x), and optionally document engines expectations. Overall: non-blocking comments under the trivial/docs-only calibration, but recommended fixes should be made before merge to keep CI green.
Findings
- [NON-BLOCKING] bun.lock:1 — Lockfile is stale: still resolves @eslint/js 9.29.0 while package.json requires 10.0.1; CI uses --frozen-lockfile and will fail
The root bun.lock still pins @eslint/js at 9.29.0 under workspaces[""] -> devDependencies and in the packages map (e.g., the entry "@eslint/js": ["@eslint/js@9.29.0", …]). See bun.lock top section where devDependencies lists "@eslint/js": "9.29.0". Meanwhile package.json now declares "@eslint/js": "10.0.1". The CI workflow runsbun install --frozen-lockfile(.github/workflows/ci.yml, Install dependencies step), which will error when the lockfile and manifest disagree. Please runbun installto regenerate bun.lock and commit the updated lockfile in this PR. - [NON-BLOCKING] package.json:38 — Potential peerDependency/version skew: @eslint/js v10 requires compatible eslint core; repo still pins eslint ^9.29.0
Upstream @eslint/js v10 adds a peerDependency on eslint and updates recommended configs to align with newer eslint 9.39+ (release notes commit 1f66734 and 454a292). Your package.json sets "@eslint/js": "10.0.1" but keeps "eslint": "^9.29.0". eslint.config.js imports @eslint/js and uses js.configs.recommended, which in v10 changes rule coverage. This skew can lead to missing rule definitions or schema mismatches and will surface as peer warnings/failures under stricter installers. Suggestion: bump devDependencies.eslint to a compatible version (e.g., >= 9.39.x matching @eslint/js 10.0.1) and update bun.lock accordingly. - [NON-BLOCKING] .github/workflows/ci.yml:27 — CI reproducibility hinges on bun.lock update; current mismatch will break the frozen-lockfile install
The workflow usesbun install --frozen-lockfile(line ~27). With package.json now specifying "@eslint/js": "10.0.1" while bun.lock still resolves 9.29.0, the install step will deterministically fail, breaking CI. Ensure bun.lock is regenerated and committed in this PR to keep the pipeline green after merging this dependency bump. - [NON-BLOCKING] package.json:1 — Engines/Runtime note: @eslint/js v10 release notes require Node ^20.19.0 || ^22.13.0 || >=24; verify local/CI environments
While CI runs lint under Bun 1.2.21, upstream @eslint/js v10 indicates a Node.js engines constraint. Some environments (precommit hooks, local dev using Node) may run ESLint under Node and could hit engines warnings or failures if Node <20.19 is used. Consider documenting the required Node versions in CONTRIBUTING.md or adding an "engines" field to package.json if Node is a supported runtime for tooling, or confirm Bun-only execution avoids engines enforcement.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies shows "@eslint/js": "10.0.1" replacing 9.29.0. |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json devDependencies keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to 10.0.1; eslint.config.js imports js.configs.recommended which may depend on newer eslint core. |
55f1e24 to
3b1fc78
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Single-line dev-dependency bump is incomplete operationally. The lockfile remains stale (bun.lock still has @eslint/js 9.29.0) and CI uses --frozen-lockfile, so installs will fail until bun.lock is regenerated. Also, @eslint/js v10 adds an eslint peer and updates eslint:recommended; keeping eslint at ^9.29.0 risks peer warnings or missing-rule errors—please bump eslint to a compatible 9.39.x+ and update the lockfile. Minor nits in eslint.config.js (duplicate ignore entry and stray double slashes in patterns) can be tidied while you’re here. Under the trivial/docs-only calibration these are non-blocking, but addressing them before merge will keep the pipeline green.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
The rootbun.lockstill pins@eslint/jsat9.29.0underworkspaces[""] -> devDependenciesand in thepackagesmap (e.g., the entry"@eslint/js": ["@eslint/js@9.29.0", …]). Meanwhilepackage.jsondeclares"@eslint/js": "10.0.1".
Evidence:
bun.lock: top-leveldevDependenciesshows"@eslint/js": "9.29.0"and there is apackagesentry for@eslint/js@9.29.0..github/workflows/ci.yml: Install dependenciesstep runsbun install --frozen-lockfile, which errors when the manifest and lockfile disagree.
Action: run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR.
- [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/jsv10 adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/jsv10 added apeerDependenciesentry foreslintand updatedeslint:recommended(see release notes commit1f66734and454a292). This repo now uses"@eslint/js": "10.0.1"but still has"eslint": "^9.29.0". Youreslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 can reference rules only present in newereslintcores.
Risks:
- Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
- Runtime errors like “Definition for rule '…' was not found” or option schema mismatches.
Evidence:
package.jsondevDependencies:"@eslint/js": "10.0.1","eslint": "^9.29.0".eslint.config.js:1imports@eslint/jsand usesjs.configs.recommended.
Suggestion: Bump devDependencies.eslint to a version compatible with @eslint/js@10.0.1 (e.g., ^9.39.x or newer per upstream) and update the lockfile.
- [NON-BLOCKING] eslint.config.js:15 — Duplicate ignore pattern for
eslint-rules/__fixtures__/inignoreslist
Theignoresarray lists"eslint-rules/__fixtures__/**"twice (first near the top of the list and again at the end of theignoresblock). This is harmless but noisy for maintenance and suggests the ignore set wasn’t deduped during this bump.
Evidence: eslint.config.js ignores array contains two identical entries for the same path pattern.
Suggestion: Remove one duplicate to keep the configuration tidy.
- [NON-BLOCKING] eslint.config.js:197 — Typos in
no-restricted-importspatterns: double slashes in"../../..//*.jsx"and"../..//*.tsx"
Within theno-restricted-importsrulepatterns, two entries include a stray extra slash:"../../..//*.jsx"and"../..//*.tsx". These likely won’t match as intended and appear to be accidental. While pre-existing, they become higher-risk when updating@eslint/jsas pattern handling may have changed across versions.
Suggestion: Normalize these patterns to "../../../*.jsx" and "../../*.tsx" (or whatever the intended depth was) to ensure consistent enforcement.
Inline comments
- .github/workflows/ci.yml:24 — Heads-up: with
bun install --frozen-lockfile, the current mismatch betweenpackage.json(@eslint/js10.0.1) andbun.lock(still@eslint/js9.29.0) will cause this step to fail. Regenerate and commitbun.lockafter bumping to keep CI green. - package.json:38 —
@eslint/jsv10 declares apeerDependenciesrequirement oneslintand updateseslint:recommended. Consider bumpingeslintfrom^9.29.0to a compatible^9.39.x+ to avoid peer warnings or missing-rule errors withjs.configs.recommended.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies shows "@eslint/js": "10.0.1" replacing 9.29.0. |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to "10.0.1"; eslint.config.js uses js.configs.recommended. Recommend bumping eslint to a compatible version (>=9.39.x) and updating bun.lock. |
3b1fc78 to
e95abfd
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Verification of the latest commit shows this PR only bumps @eslint/js in package.json. The prior non-blocking concerns remain: the bun.lock still resolves @eslint/js@9.29.0 while CI installs with --frozen-lockfile, so the pipeline will fail until the lockfile is regenerated. Additionally, eslint remains pinned at ^9.29.0 even though @eslint/js@10 adds a peer on eslint and updates eslint:recommended — consider bumping eslint to a compatible 9.39.x+ and updating the lockfile. I also noted two small config nits in eslint.config.js (a duplicate ignore pattern and two patterns with double slashes). No new critical or user-facing behavior issues were introduced. Please regenerate bun.lock (and optionally align eslint) to keep CI green.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
bun.lockstill pins@eslint/jsat9.29.0underworkspaces[""] -> devDependenciesand in thepackagesmap (there is an entry for@eslint/js@9.29.0). Meanwhilepackage.jsondeclares"@eslint/js": "10.0.1". The CI workflow runsbun install --frozen-lockfile(see.github/workflows/ci.yml, Install dependencies step), which errors when the manifest and lockfile disagree. Please runbun installlocally to regeneratebun.lockwith@eslint/js@10.0.1and commit the updated lockfile in this PR. - [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/js@10adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/jsv10 adds apeerDependenciesrequirement oneslintand updateseslint:recommended(release notes commits1f66734and454a292). In this repo,package.jsonsets"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0".eslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 may reference rules only present in newereslintcores. Risks: peer resolution warnings/errors under stricter installers or future Bun, and runtime errors like “Definition for rule '…' was not found.” Suggestion: bumpdevDependencies.eslintto a compatible version (e.g.,^9.39.x+) and updatebun.lockaccordingly. - [NON-BLOCKING] eslint.config.js:15 — Duplicate ignore pattern for
eslint-rules/__fixtures__/inignoreslist
Theignoresarray contains the same entry"eslint-rules/__fixtures__/**"twice (once at the start of the list and again at the bottom of the same block). This is harmless but adds noise. Suggest removing the duplicate to keep the configuration tidy. - [NON-BLOCKING] eslint.config.js:197 — Typos in
no-restricted-importspatterns: stray double slashes in two entries
Within theno-restricted-importsrulepatterns, two entries include an extra slash:"../../..//*.jsx"and"../..//*.tsx". These likely won’t match as intended and appear accidental. Consider normalizing to"../../../*.jsx"and"../../*.tsx"(or the intended depth) to ensure consistent enforcement.
e95abfd to
c9d15f8
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Verified the bump to @eslint/js 10.0.1 in package.json. However, the root bun.lock still resolves @eslint/js@9.29.0 while CI uses bun install --frozen-lockfile, which will fail; please regenerate and commit the lockfile. Also, @eslint/js@10 now peers on eslint, but eslint remains at ^9.29.0; consider bumping to a compatible ^9.39.x+ to avoid peer/resolution issues. Minor nits: duplicate ignore entry in eslint.config.js and two stray // in restricted import patterns. Under the trivial/docs-only calibration, these are non-blocking; overall event is COMMENT.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
bun.lockstill pins@eslint/jsat9.29.0underworkspaces[""] -> devDependenciesand in thepackagesmap (there is an entry for@eslint/js@9.29.0). Meanwhilepackage.jsondeclares"@eslint/js": "10.0.1". The CI workflow runsbun install --frozen-lockfile(see.github/workflows/ci.yml, Install dependencies step), which errors when the manifest and lockfile disagree.
Action: run bun install to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR.
- [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/js@10adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/jsv10 adds apeerDependenciesrequirement oneslintand updateseslint:recommended. In this repo,package.jsonsets"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0".eslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 may reference rules only present in newereslintcores.
Risks:
- Peer resolution warnings/errors under stricter installers or future Bun.
- Runtime errors like “Definition for rule '…' was not found.”
Suggestion: Bump devDependencies.eslint to a compatible version (e.g., ^9.39.x+) and update bun.lock accordingly.
Inline comments
- .github/workflows/ci.yml:24 — Heads-up: with
bun install --frozen-lockfile, the current mismatch betweenpackage.json(@eslint/js10.0.1) andbun.lock(still@eslint/js9.29.0) will cause this step to fail. Please regenerate and commitbun.lockafter bumping to keep CI green. - eslint.config.js:15 — Duplicate ignore entry:
"eslint-rules/__fixtures__/**"appears twice in theignoresarray. Not harmful, but removing the duplicate would keep the config tidy. - eslint.config.js:197 — Nit: Two
no-restricted-importspattern entries have stray double slashes:"../../..//*.jsx"and"../..//*.tsx". Consider normalizing to"../../../*.jsx"and"../../*.tsx"(or the intended depth) to ensure patterns match as expected.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies shows "@eslint/js": "10.0.1" replacing 9.29.0 (package.json: devDependencies block). |
| Keep dependency graph/install reproducible (update lockfile to match manifest). | Not Met | bun.lock top-level workspaces[""] -> devDependencies lists "@eslint/js": "9.29.0", while package.json declares "@eslint/js": "10.0.1". .github/workflows/ci.yml uses bun install --frozen-lockfile which will fail on this mismatch. |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to 10.0.1 (package.json devDependencies). eslint.config.js imports @eslint/js and uses js.configs.recommended, which in v10 may rely on rules present in newer eslint cores. |
c9d15f8 to
ec907e9
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
The bump in package.json to @eslint/js 10.0.1 is present, but the lockfile remains stale and still pins @eslint/js 9.29.0. Because CI installs with --frozen-lockfile, this mismatch will cause the install step to fail after merge. Also, @eslint/js v10 introduces a peerDependency on eslint; the repo still pins eslint at ^9.29.0, which risks peer warnings or missing-rule errors when using js.configs.recommended. Please regenerate bun.lock and consider bumping eslint to a compatible 9.39.x+ to keep lint stable. No additional code or scope changes observed.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still pins
@eslint/js@9.29.0whilepackage.jsonnow requires10.0.1; CI uses--frozen-lockfileand will fail
The rootbun.locktop section (workspaces[""] -> devDependencies) still lists"@eslint/js": "9.29.0", and there is apackagesentry for@eslint/js@9.29.0. Meanwhilepackage.jsondeclares"@eslint/js": "10.0.1"indevDependencies.
CI installs with a frozen lockfile (see .github/workflows/ci.yml, Install dependencies step), which errors when the manifest and lockfile disagree. Please run bun install and commit the updated bun.lock so CI remains reproducible and green after this bump.
- [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/js@10now peerseslint, buteslintremains^9.29.0
Per the upstream release notes you included,@eslint/js@10adds apeerDependenciesrequirement oneslintand updateseslint:recommended. In this repo,package.jsonsets"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0". Youreslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 may reference rules only present in newereslintcores.
Risks:
- Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
- Runtime errors like “Definition for rule '…' was not found” or option schema mismatches.
Suggestion: bump devDependencies.eslint to a version compatible with @eslint/js@10.0.1 (e.g., ^9.39.x+) and update bun.lock accordingly.
Inline comments
- .github/workflows/ci.yml:24 — Heads-up:
bun install --frozen-lockfilewill fail with the current mismatch betweenpackage.json(@eslint/js10.0.1) andbun.lock(still@eslint/js9.29.0). Please regenerate and commitbun.lockafter bumping to keep CI green.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies now lists "@eslint/js": "10.0.1" (package.json: devDependencies block). |
| Keep dependency graph/install reproducible (update lockfile to match manifest). | Not Met | bun.lock top-level workspaces[""] -> devDependencies still lists "@eslint/js": "9.29.0" while package.json declares "@eslint/js": "10.0.1". CI uses bun install --frozen-lockfile (.github/workflows/ci.yml:24). |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to 10.0.1 (package.json devDependencies). Upstream @eslint/js@10 adds an eslint peerDependency; eslint.config.js uses js.configs.recommended from @eslint/js v10. |
ec907e9 to
02de415
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
conclude_review call. Event derived from severity counts: COMMENT (0 BLOCKING / 4 NON-BLOCKING / 0 PRE-EXISTING findings). Executive summary unavailable.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
bun.locktop-levelworkspaces[""] -> devDependenciesstill lists"@eslint/js": "9.29.0", and there’s apackagesentry for@eslint/js@9.29.0. Meanwhilepackage.jsonnow declares"@eslint/js": "10.0.1"indevDependencies.
CI installs with a frozen lockfile (.github/workflows/ci.yml, Install dependencies step: bun install --frozen-lockfile --no-progress), which errors when the manifest and lockfile disagree. Please run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile so CI remains reproducible and green.
Evidence:
package.json: devDependencies->"@eslint/js": "10.0.1"bun.lock:12andpackagesmap ->@eslint/js@9.29.0.github/workflows/ci.yml:26->bun install --frozen-lockfile --no-progress- [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/js@10adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/jsv10 adds apeerDependenciesrequirement oneslintand updateseslint:recommended. This repo now uses"@eslint/js": "10.0.1"but still has"eslint": "^9.29.0". Youreslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 can reference rules present only in newereslintcores.
Risks:
- Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
- Runtime errors like “Definition for rule '…' was not found” or option schema mismatches.
Suggestion: Bump devDependencies.eslint to a version compatible with @eslint/js@10.0.1 (e.g., ^9.39.x+) and update bun.lock accordingly.
Evidence:
package.json: devDependencies->"@eslint/js": "10.0.1","eslint": "^9.29.0"eslint.config.js:1imports@eslint/jsand usesjs.configs.recommended.- [NON-BLOCKING] eslint.config.js:15 — Duplicate ignore entry for
"eslint-rules/__fixtures__/**"inignoreslist
Theignoresarray contains the same entry"eslint-rules/__fixtures__/**"twice (once at the start of the block and again at the end). This is harmless but adds noise and can confuse future edits.
Suggestion: Remove one of the duplicate entries to keep the configuration tidy.
Evidence: eslint.config.js:15-42 contains the ignores array with two identical lines for "eslint-rules/__fixtures__/**".
- [NON-BLOCKING] eslint.config.js:197 — Stray double slashes in
no-restricted-importspatterns may not match as intended
Within theno-restricted-importsrulepatterns, two entries have an extra slash:"../../..//*.jsx"and"../..//*.tsx". These are likely typos and may fail to match paths as intended.
Suggestion: Normalize to "../../../*.jsx" and "../../*.tsx" (or the intended depths) to ensure consistent enforcement.
Evidence: eslint.config.js:197-241 shows the patterns groups; the affected lines include "../../..//*.jsx" and "../..//*.tsx".
02de415 to
723369a
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
The manifest correctly bumps @eslint/js to 10.0.1, but the Bun lockfile remains stale and still resolves @eslint/js@9.29.0. Given CI installs with --frozen-lockfile, this mismatch will cause the install step to fail after merge. Also, @eslint/js v10 introduces a peerDependency on eslint and updates eslint:recommended; your repo still pins eslint at ^9.29.0, which may lead to peer warnings or missing-rule errors. Under the trivial/docs-only calibration these are non-blocking, but I strongly recommend regenerating bun.lock and bumping eslint to a compatible ^9.39.x+ before merging to keep CI green and avoid resolution issues. Overall, the version bump itself is correct; addressing the lockfile and peer alignment will complete the change.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
bun.locktop-levelworkspaces[""] -> devDependenciesstill lists"@eslint/js": "9.29.0", and thepackagesmap includes an@eslint/js@9.29.0entry, whilepackage.jsonnow declares"@eslint/js": "10.0.1"indevDependencies.
The CI workflow runs bun install --frozen-lockfile --no-progress (see .github/workflows/ci.yml, Install dependencies step), which errors when the manifest and lockfile disagree. Please run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile to keep CI reproducible and green.
- [NON-BLOCKING] package.json:38 — Potential peer/version skew:
@eslint/js@10adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/jsv10 adds apeerDependenciesrequirement oneslintand updateseslint:recommended(see the PR's release notes). This repo now uses"@eslint/js": "10.0.1"but still has"eslint": "^9.29.0".
Your eslint.config.js imports @eslint/js and uses js.configs.recommended (pre-existing), which in v10 may reference rules only present in newer eslint cores. Risks:
- Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
- Runtime errors like “Definition for rule '…' was not found” or option schema mismatches.
Suggestion: bump devDependencies.eslint to a compatible ^9.39.x+ and update bun.lock accordingly, or confirm/adjust config to a set compatible with eslint@9.29.0.
Inline comments
- .github/workflows/ci.yml:26 — Heads-up: with
bun install --frozen-lockfile --no-progress, the current mismatch betweenpackage.json(@eslint/js10.0.1) andbun.lock(still@eslint/js9.29.0) will cause this step to fail. Please regenerate and commitbun.lockafter bumping to keep CI green.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies now lists "@eslint/js": "10.0.1" (package.json: devDependencies block). |
| Keep dependency graph/install reproducible (update lockfile to match manifest). | Not Met | bun.lock top-level workspaces[""] -> devDependencies lists "@eslint/js": "9.29.0" while package.json declares "@eslint/js": "10.0.1". CI uses bun install --frozen-lockfile --no-progress (.github/workflows/ci.yml:26). |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to 10.0.1. eslint.config.js (pre-existing) uses js.configs.recommended from @eslint/js. Recommend bumping eslint to a compatible ^9.39.x+ to avoid peer warnings or missing-rule errors. |
dependabot
Bot
changed the title
723369a to
229874d
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
The bump to @eslint/js is correctly applied in package.json. However, bun.lock still resolves @eslint/js at 9.29.0 while CI installs with --frozen-lockfile, which will cause deterministic CI failures until the lockfile is regenerated. Also, @eslint/js v10 introduces an eslint peer; eslint remains at ^9.29.0, which can lead to peer warnings or missing-rule errors with js.configs.recommended. I’ve also noted two minor nits in eslint.config.js (a duplicate ignore entry and two patterns with double slashes). Given the PR’s trivial scope, I’m filing these as non-blocking, but I recommend regenerating bun.lock and considering an eslint bump to keep CI and tooling happy.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI uses--frozen-lockfileand will fail
The rootbun.lockstill pins@eslint/jsat9.29.0underworkspaces[""] -> devDependenciesand in thepackagesmap (see top section where"@eslint/js": "9.29.0"). Meanwhilepackage.jsondeclares"@eslint/js": "10.0.1"indevDependencies.
The CI workflow runs bun install --frozen-lockfile --no-progress (see .github/workflows/ci.yml, Install dependencies step), which errors when the manifest and lockfile disagree. Please run bun install to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR to keep CI green.
-
[NON-BLOCKING] package.json:70 — Potential peer/version skew:
@eslint/js@10now peerseslint, buteslintremains^9.29.0
Upstream@eslint/jsv10 adds apeerDependenciesrequirement oneslintand updateseslint:recommended. This repo bumps"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0". Youreslint.config.jsimports@eslint/jsand usesjs.configs.recommended, which in v10 may reference rules only present in newereslintcores. Risks: -
Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
-
Runtime errors like “Definition for rule '…' was not found” or option schema mismatches.
Suggestion: bump devDependencies.eslint to a compatible ^9.39.x+ and update bun.lock accordingly, or confirm/adjust config to a set compatible with eslint@9.29.0.
Inline comments
- eslint.config.js:15 — Nit:
ignorescontains a duplicate entry for"eslint-rules/__fixtures__/**"(also appears again near the end of this block). It’s harmless but removing the duplicate would keep the config tidy. - eslint.config.js:197 — Two
no-restricted-importspatternsentries have stray double slashes:"../../..//*.jsx"and"../..//*.tsx". Consider normalizing to"../../../*.jsx"and"../../*.tsx"(or the intended depth) to ensure matching behaves as expected.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies shows "@eslint/js": "10.0.1" replacing 9.29.0 (package.json:70-74). |
| Keep dependency graph/install reproducible (update lockfile to match manifest). | Not Met | bun.lock still resolves @eslint/js as 9.29.0 (bun.lock: top-level workspaces[""] -> devDependencies and packages map), while package.json declares 10.0.1. CI installs with --frozen-lockfile (.github/workflows/ci.yml:26). |
| Ensure compatibility with new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to "10.0.1"; eslint.config.js imports and uses js.configs.recommended (eslint.config.js:1, 21). Upstream @eslint/js v10 adds an eslint peerDependency per release notes. |
dependabot
Bot
changed the title
229874d to
0ade823
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
Verification round: the only code change bumps @eslint/js in package.json. Prior non-blocking findings persist. Specifically, bun.lock still pins @eslint/js at 9.29.0 while package.json now requires 10.0.1; with bun install --frozen-lockfile in CI, this will fail until the lockfile is regenerated. Also, @eslint/js v10 adds a peerDependency on eslint; this repo still has eslint ^9.29.0, which may cause peer warnings or rule mismatches. No new blocking issues surfaced for this trivial/dev-deps bump. Please regenerate bun.lock (and consider bumping eslint) to keep CI green, then this is good to merge.
Findings
- [NON-BLOCKING] bun.lock:12 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonnow requires10.0.1; CI uses--frozen-lockfileand will fail
bun.locktop-levelworkspaces[""] -> devDependenciesstill lists"@eslint/js": "9.29.0", and thepackagesmap includes an@eslint/js@9.29.0entry. Meanwhilepackage.jsonnow declares"@eslint/js": "10.0.1"indevDependencies(package.json: devDependencies).
Your workflow installs with a frozen lockfile (see .github/workflows/ci.yml, Install dependencies step: bun install --frozen-lockfile --no-progress), which deterministically errors when the manifest and lockfile disagree.
Action: run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR to keep CI reproducible and green.
- [NON-BLOCKING] package.json:66 — Potential peer/version skew:
@eslint/js@10adds a peerDependency oneslint, but repo still pinseslintat^9.29.0
Upstream@eslint/js@10adds apeerDependenciesrequirement oneslintand updateseslint:recommended. In this repo,package.jsonsets"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0"(package.json: devDependencies). Youreslint.config.jsimports@eslint/jsand commonly usesjs.configs.recommendedin such setups; with v10 that may reference rules present only in newereslintcores.
Risks:
- Peer resolution warnings/errors under stricter installers (pnpm/yarn PnP) or future Bun.
- Runtime lint errors like “Definition for rule '…' was not found” or schema mismatches.
Suggestion: bump devDependencies.eslint to a compatible ^9.39.x+ and update bun.lock accordingly, or confirm/adjust the config to a set compatible with eslint@9.29.0.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies shows "@eslint/js": "10.0.1" replacing 9.29.0 (package.json:66-90). |
| Keep dependency graph/install reproducible (update lockfile to match manifest). | Not Met | bun.lock top-level workspaces[""] -> devDependencies lists "@eslint/js": "9.29.0" while package.json declares "@eslint/js": "10.0.1". CI uses bun install --frozen-lockfile --no-progress which will fail on mismatch (.github/workflows/ci.yml: Install dependencies step). |
| Ensure compatibility with the new peerDependency on eslint introduced in @eslint/js v10. | Not Met | package.json keeps "eslint": "^9.29.0" while upgrading "@eslint/js" to "10.0.1" (package.json devDependencies). Upstream @eslint/js v10 adds an eslint peerDependency; configs using @eslint/js v10 may assume newer eslint core. |
0ade823 to
51cca3a
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown
The PR cleanly bumps @eslint/js to 10.0.1 in package.json. Prior non-blocking concerns remain: bun.lock still resolves @eslint/js@9.29.0 (CI uses --frozen-lockfile) and there’s potential peer skew with eslint still at ^9.29.0. Additionally, eslint.config.js has a duplicate ignore pattern and two minor pattern typos. None of these are critical for this trivial deps-only change. I find no new blocking issues introduced by this commit. Verdict: APPROVE. Please regenerate bun.lock and consider aligning eslint in a follow-up.
Findings
- [NON-BLOCKING] bun.lock:1 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonnow requires10.0.1; CI installs with--frozen-lockfile
bun.lockstill pins@eslint/jsat9.29.0under the root workspace'sdevDependenciesand in thepackagesmap, whilepackage.jsonhas"@eslint/js": "10.0.1".
Evidence:
package.json:devDependencies→"@eslint/js": "10.0.1".bun.lock: root workspacedevDependenciesshows"@eslint/js": "9.29.0", and there is apackagesentry for@eslint/js@9.29.0..github/workflows/ci.ymlinstalls withbun install --frozen-lockfile --no-progress, which will error on a manifest/lock mismatch.
Action: run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR.
- [NON-BLOCKING] package.json:52 — Potential peer/version skew:
@eslint/js@10peerseslint, but repo still pinseslintat^9.29.0
Upstream@eslint/js@10adds apeerDependenciesrequirement oneslintand updateseslint:recommended. This repo now uses"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0".
Evidence:
package.jsondevDependencies:"@eslint/js": "10.0.1","eslint": "^9.29.0".eslint.config.jsimports@eslint/jsand usesjs.configs.recommended.
Risks:
- Peer resolution warnings/errors under stricter installers.
- Runtime lint errors like “Definition for rule '…' was not found” if
eslintcore is too old for@eslint/js@10's config.
Suggestion: Bump devDependencies.eslint to a compatible ^9.39.x+ (per upstream releases) and update bun.lock accordingly, or pin an @eslint/js 10-compatible eslint version explicitly.
- [NON-BLOCKING] eslint.config.js:21 — Duplicate ignore entry for
"eslint-rules/__fixtures__/**"in theignoresarray
Theignoreslist contains"eslint-rules/__fixtures__/**"twice (at the top of the array and again near the end of the same block). This duplication is harmless but creates unnecessary noise and may confuse future edits.
Evidence: eslint.config.js lines ~21 and ~41 both include the same ignore pattern.
Suggestion: Remove one of the duplicate entries to keep the configuration tidy.
- [NON-BLOCKING] eslint.config.js:197 — Stray double slashes in
no-restricted-importspatterns ("../../..//*.jsx","../..//*.tsx")
Within theno-restricted-importspatterns, two entries include an extra slash:"../../..//*.jsx"and"../..//*.tsx". These look like typos and may not match as intended.
Evidence: eslint.config.js patterns groups for *.jsx and *.tsx (around lines 197–241) contain those entries with ..//.
Suggestion: Normalize to "../../../*.jsx" and "../../*.tsx" (or your intended depths) to ensure pattern matching behaves as expected.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies now lists "@eslint/js": "10.0.1" (package.json: lines ~48-76). |
51cca3a to
9a9ac21
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: 3
The package.json bump to @eslint/js@10.0.1 is correct and matches the PR’s stated intent. I re-verified prior concerns: the lockfile remains stale (still pins @eslint/js@9.29.0) and there’s a potential peer skew with eslint@^9.29.0 against @eslint/js@10—both are non-blocking for this trivial bump but should be addressed to keep CI green and avoid peer warnings. Minor config nits also remain (duplicate ignore entry and two stray ..// patterns in eslint.config.js). No new critical issues were introduced by this change. Verdict: APPROVE.
Findings
- [NON-BLOCKING] bun.lock:1 — Lockfile is stale: still resolves
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; CI installs with--frozen-lockfile
The rootbun.lockcontinues to pin@eslint/jsat9.29.0under the root workspace'sdevDependenciesand in thepackagesmap, whilepackage.jsondeclares"@eslint/js": "10.0.1".
Evidence:
package.json:devDependencies→"@eslint/js": "10.0.1".bun.lock: top-levelworkspaces[""] -> devDependenciesshows"@eslint/js": "9.29.0", and thepackagessection contains an entry for@eslint/js@9.29.0..github/workflows/ci.yml(Install step) usesbun install --frozen-lockfile --no-progress, which errors on manifest/lockfile mismatches.
Action: run bun install locally to regenerate bun.lock with @eslint/js@10.0.1 and commit the updated lockfile in this PR to keep CI reproducible and green.
- [NON-BLOCKING] eslint.config.js:21 — Duplicate ignore entry for
"eslint-rules/__fixtures__/**"in theignoresarray
Theignoreslist includes"eslint-rules/__fixtures__/**"twice (once at the top of the block and again at the bottom). This duplication is harmless but creates unnecessary noise and may confuse future edits.
Evidence: eslint.config.js:21 and later in the same ignores array contain identical entries.
Suggestion: Remove one of the duplicate entries to keep the configuration tidy.
- [NON-BLOCKING] eslint.config.js:197 — Stray double slashes in
no-restricted-importspatterns ("../../..//*.jsx","../..//*.tsx")
Within theno-restricted-importsrulepatterns, two entries include an extra slash:"../../..//*.jsx"and"../..//*.tsx". These look like typos and may not match as intended.
Evidence: eslint.config.js patterns groups for *.jsx and *.tsx contain those entries with ..//.
Suggestion: Normalize to "../../../*.jsx" and "../../*.tsx" (or your intended depths) to ensure pattern matching behaves as expected.
- [NON-BLOCKING] package.json:48 — Potential peer/version skew:
@eslint/js@10peerseslint, buteslintremains^9.29.0
Upstream@eslint/js@10adds apeerDependenciesrequirement oneslintand updateseslint:recommended. This repo now uses"@eslint/js": "10.0.1"but keeps"eslint": "^9.29.0". Youreslint.config.jsimports@eslint/jsand usesjs.configs.recommended.
Risks:
- Peer resolution warnings/errors under stricter installers.
- Runtime lint errors like “Definition for rule '…' was not found” if the
eslintcore is too old for@eslint/js@10's config.
Suggestion: Bump devDependencies.eslint to a compatible ^9.39.x+ and update bun.lock accordingly, or pin an @eslint/js 10-compatible eslint version explicitly.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies now lists "@eslint/js": "10.0.1" replacing 9.29.0 (package.json: devDependencies block). |
Bumps [@eslint/js](https://github.com/eslint/eslint/tree/HEAD/packages/js) from 9.29.0 to 10.0.1. - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](https://github.com/eslint/eslint/commits/v10.0.1/packages/js) --- updated-dependencies: - dependency-name: "@eslint/js" dependency-version: 10.0.1 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
9a9ac21 to
f24b63e
Compare
There was a problem hiding this comment.
Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: 3
Verified the PR updates @eslint/js to 10.0.1 in package.json. The only remaining issue is non-blocking for this trivial deps-only bump: bun.lock still pins @eslint/js@9.29.0, which can cause frozen installs to fail. Recommend regenerating and committing the lockfile in a follow-up to keep CI green. No critical correctness, security, or scope issues introduced; approving.
Findings
- [NON-BLOCKING] bun.lock:1 — Lockfile still pins
@eslint/js@9.29.0whilepackage.jsonrequires10.0.1; frozen installs may fail
package.jsonnow declares"@eslint/js": "10.0.1"indevDependencies(seepackage.json: devDependencies), but the rootbun.lockcontinues to list"@eslint/js": "9.29.0"under the root workspace and in thepackagesmap. Your CI uses a frozen install (bun install --frozen-lockfile --no-progressper.github/workflows/ci.ymlin prior context), which errors on manifest/lockfile mismatches. Suggestion: runbun installand commit the refreshedbun.lockto keep installs reproducible and CI green.
Spec verification
| Criterion | Status | Evidence |
|---|---|---|
| Bump @eslint/js from 9.29.0 to 10.0.1 in package.json. | Met | package.json: devDependencies now shows "@eslint/js": "10.0.1" (package.json: devDependencies block at lines ~60-95). |
Bumps @eslint/js from 9.29.0 to 10.0.1.
Release notes
Sourced from @eslint/js's releases.
... (truncated)
Commits
84fb885chore: package.json update for@eslint/jsrelease1f66734chore: addeslinttopeerDependenciesof@eslint/js(#20467)f3fbc2fchore: set@eslint/jsversion to 10.0.0 to skip releasing it (#20466)b4b3127chore: package.json update for@eslint/jsrelease0b14059chore: package.json update for@eslint/jsreleasefa31a60feat!: addnameto configs (#20015)1e2cad5chore: package.json update for@eslint/jsrelease454a292feat!: updateeslint:recommendedconfiguration (#20210)c6358c3feat!: Require Node.js^20.19.0 || ^22.13.0 || >=24(#20160)c7ebefcchore: package.json update for@eslint/jsrelease