build(deps-dev): bump lint-staged from 15.5.2 to 17.0.8

[dependabot]

Bumps lint-staged from 15.5.2 to 17.0.8.

Release notes

Sourced from lint-staged's releases.

v17.0.8

Patch Changes

• #1809 179b437 - Fix lint-staged discarding the ongoing merge conflict status (.git/MERGE_HEAD) when using the --hide-unstaged or --hide-all options.

• #1811 3d0b2c0 - Fix issues with Git commands that are successful but also emit warnings to stderr, by ignoring the stderr output completely when the process exits with code 0. This was the behavior when using nano-spawn and execa, but when switching to tinyexec in 16.3.0 both stdout and stderr were used as interleaved output.

v17.0.7

Patch Changes

• #1806 e692e58 - Update dependency tinyexec@^1.2.4.

v17.0.6

Patch Changes

• #1803 bdf2770 - Run all tests with Deno, in addition to Node.js and Bun.

• #1796 7508272 - Fix performance regression of lint-staged v17 by going back to using git add to stage task modifications. This was changed to git update-index --again in v17 for less manual work, but unfortunately the update-index command gets slower in very large Git repos.

• #1797 7b2505a - This version of lint-staged uses the new staged publishing for npm packages feature. Releases are already published from GitHub Actions with trusted publishing, but now an additional approval with two-factor authentication is also required.

• #1802 321b0a9 - Downgrade dependency tinyexec@1.2.2 to avoid issues in version 1.2.3.

v17.0.5

Patch Changes

• #1792 1f67271 - Correctly set the --max-arg-length default value based on the running platform. This controls how very long lists of staged files are split into multiple chunks.

v17.0.4

Patch Changes

• #1788 f95c1f8 - Another fix for making sure lint-staged adds task modifications correctly to the commit in the following cases:

  • after editing <file> it is staged with git add <file>, and then committed with git commit
  • after editing <file> it is committed with git commit --all without explicit git add
  • after editing <file> it is committed with git commit <pathspec> without explicit git add

  There's new test cases which actually setup the Git pre_commit hook to run lint-staged and verify them. These issues started in v17.0.0 when trying to improve support for committig without having explicitly staged files.

v17.0.3

Patch Changes

• #1782 06813f9 Thanks @​iiroj! - Fix lint-staged behavior when implicitly committing files without using git add by either:
  • git commit -am "my commit message" where -a (--all) means to automatically stage all tracked modified and deleted files
  • git commit -m "my commit message" . where . is an example of a pathspec where matching files will be staged

v17.0.2

Patch Changes

• #1779 88670ca Thanks @​iiroj! - Enable immutable GitHub releases

... (truncated)

Changelog

Sourced from lint-staged's changelog.

17.0.8

Patch Changes

• #1809 179b437 - Fix lint-staged discarding the ongoing merge conflict status (.git/MERGE_HEAD) when using the --hide-unstaged or --hide-all options.

• #1811 3d0b2c0 - Fix issues with Git commands that are successful but also emit warnings to stderr, by ignoring the stderr output completely when the process exits with code 0. This was the behavior when using nano-spawn and execa, but when switching to tinyexec in 16.3.0 both stdout and stderr were used as interleaved output.

17.0.7

Patch Changes

• #1806 e692e58 - Update dependency tinyexec@^1.2.4.

17.0.6

Patch Changes

• #1803 bdf2770 - Run all tests with Deno, in addition to Node.js and Bun.

• #1796 7508272 - Fix performance regression of lint-staged v17 by going back to using git add to stage task modifications. This was changed to git update-index --again in v17 for less manual work, but unfortunately the update-index command gets slower in very large Git repos.

• #1797 7b2505a - This version of lint-staged uses the new staged publishing for npm packages feature. Releases are already published from GitHub Actions with trusted publishing, but now an additional approval with two-factor authentication is also required.

• #1802 321b0a9 - Downgrade dependency tinyexec@1.2.2 to avoid issues in version 1.2.3.

17.0.5

Patch Changes

• #1792 1f67271 - Correctly set the --max-arg-length default value based on the running platform. This controls how very long lists of staged files are split into multiple chunks.

17.0.4

Patch Changes

• #1788 f95c1f8 - Another fix for making sure lint-staged adds task modifications correctly to the commit in the following cases:

  • after editing <file> it is staged with git add <file>, and then committed with git commit
  • after editing <file> it is committed with git commit --all without explicit git add
  • after editing <file> it is committed with git commit <pathspec> without explicit git add

  There's new test cases which actually setup the Git pre_commit hook to run lint-staged and verify them. These issues started in v17.0.0 when trying to improve support for committig without having explicitly staged files.

17.0.3

Patch Changes

• #1782 06813f9 Thanks @​iiroj! - Fix lint-staged behavior when implicitly committing files without using git add by either:
  • git commit -am "my commit message" where -a (--all) means to automatically stage all tracked modified and deleted files
  • git commit -m "my commit message" . where . is an example of a pathspec where matching files will be staged

... (truncated)

Commits

• 5f3b8f2 Merge pull request #1812 from lint-staged/changeset-release/main
• 43a9b8d chore(changeset): release
• 630e2f6 Merge pull request #1809 from lint-staged/restore-merge-status
• 179b437 fix: restore Git merge status after creating backup stash
• 6bae2e2 Merge pull request #1811 from lint-staged/exec-git-ignore-stderr
• b82a830 ci: run npm audit omitting dev, including prod dependencies
• 0b19b80 build(deps): update dependencies
• 3d0b2c0 fix: ignore stderr when doing Git operations
• cd11fec Merge pull request #1807 from lint-staged/changeset-release/main
• 15a8ee0 chore(changeset): release
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for lint-staged since your current version.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: request_changes

Summary: This dev-dependency bump raises lint-staged from 15.x to 17.0.8, which declares engines: node >=22.22.1 — but the repo's own engines.node is >=20.12.0. Any contributor or CI runner on Node 20.x (an explicitly supported version) will have the pre-commit hook fail. Either drop Node 20 support deliberately or pin lint-staged back to a Node-20-compatible line.

Findings (1)

1. [P1] lint-staged 17 requires Node ≥22.22.1 but the repo supports Node ≥20.12.0 — package.json:28

Sources: Verifier, Architect, Pattern, Judge-verified

pnpm-lock.yaml declares for the newly-pinned version:

lint-staged@17.0.8:
  engines: {node: '>=22.22.1'}
listr2@10.2.2:            # transitive dep of lint-staged 17
  engines: {node: '>=22.13.0'}

But package.json declares:

"engines": { "node": ">=20.12.0" }

This is a real compatibility mismatch, not just a lint warning. Contributors and CI runners on Node 20.x — which the project explicitly supports — will hit engine-check failures (or broken behavior under engine-strict) when the Husky pre-commit hook invokes lint-staged. The Architect independently flagged the related cli-truncate@5.2.0 (node >=20) bump, but the binding constraint is lint-staged/listr2 requiring Node 22, which is the actual break for Node 20 users.

Resolve one of two ways:

• Keep Node 20 support: pin back to the 15.x line (lint-staged@^15.5.2, supports Node 18+), or the newest release still compatible with Node 20.
• Drop Node 20 support (if intentional): bump engines.node to >=22.22.1 and align .nvmrc / Volta / CI runner images and contributor docs accordingly.

(Rated P1 rather than P0: this breaks dev/CI tooling for Node 20 users, but is a recoverable local-tooling failure with a clear workaround rather than a production/runtime defect.)

---

Suggestions (1)

• Consider a CI job that runs the pre-commit workflow (e.g. pnpm exec lint-staged against a sample staged change) so future major bumps in dev tooling surface engine/config breakages in CI rather than on a contributor's machine.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: request_changes

Summary: This dev-dependency bump raises lint-staged from 15.x to 17.0.8, which (via itself and its transitive dep listr2) requires Node ≥22.22.1 — but the repo declares engines.node as >=20.12.0. Contributors and CI runners on the explicitly-supported Node 20.x line will hit engine failures when the Husky pre-commit hook invokes lint-staged. Either pin back to a Node-20-compatible line or intentionally raise (and document) the repo's minimum Node version.

Findings (1)

1. [P1] lint-staged 17 requires Node ≥22.22.1 but the repo supports Node ≥20.12.0 — package.json:28

Sources: Verifier, Architect, Pattern, Judge-verified

The pinned version and its transitive dep in pnpm-lock.yaml:

lint-staged@17.0.8:
  engines: {node: '>=22.22.1'}
listr2@10.2.2:            # transitive dep of lint-staged 17
  engines: {node: '>=22.13.0'}

But package.json declares:

"engines": { "node": ">=20.12.0" }

This is a real compatibility mismatch, not just a lint warning. Contributors and CI runners on Node 20.x — an officially supported version — will hit engine-check failures (or broken behavior under engine-strict) when the Husky pre-commit hook invokes lint-staged. The Architect also noted related transitive bumps (cli-truncate@5.2.0, @csstools/*), but the binding constraint is lint-staged/listr2 requiring Node 22, which is the actual break for Node 20 users.

Resolve one of two ways:

• Keep Node 20 support: pin back to the 15.x line (lint-staged@^15.5.2, supports Node 18+) or the newest release still compatible with Node 20, and regenerate pnpm-lock.yaml.
• Drop Node 20 support (if intentional): bump engines.node to >=22.22.1, align .nvmrc / Volta / CI runner images and contributor docs, and call out the policy change in the PR description.

(Rated P1 rather than P0: this breaks dev/CI tooling for Node 20 users, but is a recoverable local-tooling failure with a clear workaround rather than a production/runtime defect.)

---

Suggestions (1)

• After choosing a Node version strategy, add a CI job that runs pnpm install and lint-staged under the lowest supported Node version, so future dependency bumps that silently raise engine requirements are caught before they break hooks.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: request_changes

Summary: This dev-dependency bump raises lint-staged from 15.x to 17.0.8, which (along with its transitive dep listr2@10.2.2) requires Node ≥22.22.1 — but the repo declares engines.node as >=20.12.0. Contributors and CI runners on the explicitly-supported Node 20.x line will hit engine-check failures when the Husky pre-commit hook invokes lint-staged. Either pin back to a Node-20-compatible line or intentionally raise (and document) the repo's minimum Node version.

Findings (1)

1. [P1] lint-staged 17 requires Node ≥22.22.1 but the repo supports Node ≥20.12.0 — package.json:28

Sources: Verifier, Architect, Pattern, Judge-verified

The newly-pinned versions in pnpm-lock.yaml:

lint-staged@17.0.8:
  engines: {node: '>=22.22.1'}
listr2@10.2.2:            # transitive dep of lint-staged 17
  engines: {node: '>=22.13.0'}

But package.json declares:

"engines": { "node": ">=20.12.0" }

This is a real compatibility mismatch, not just a lint warning. Contributors and CI runners on Node 20.x — an officially supported version — will hit engine-check failures (or broken behavior under engine-strict) when the Husky pre-commit hook invokes lint-staged. The binding constraint is lint-staged/listr2 requiring Node 22; the related transitive bumps (cli-truncate@5.2.0, @csstools/*) are secondary.

Resolve one of two ways:

• Keep Node 20 support: pin back to the 15.x line (lint-staged@^15.5.2, supports Node 18+) or the newest release still compatible with Node 20, and regenerate pnpm-lock.yaml.
• Drop Node 20 support (if intentional): bump engines.node to >=22.22.1, align .nvmrc / Volta / CI runner images and contributor docs, and call out the policy change in the PR description.

(Rated P1 rather than P0: this breaks dev/CI tooling for Node 20 users, but is a recoverable local-tooling failure with a clear workaround, not a production/runtime defect.)

---

Suggestions (1)

• Once the Node support decision is made, add a brief note to contributor docs (or README) that the pre-commit hooks rely on lint-staged and therefore require the chosen minimum Node version, so developers understand why older Node installs may fail before commit.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: request_changes

Summary: This dev-dependency bump raises lint-staged from 15.x to 17.0.8, which (along with its transitive dep listr2@10.2.2) requires Node ≥22.22.1 — but the repo declares engines.node as >=20.12.0. Contributors and CI runners on the explicitly-supported Node 20.x line will hit engine-check failures when the Husky pre-commit hook invokes lint-staged. Either pin back to a Node-20-compatible line or intentionally raise (and document) the repo's minimum Node version.

Findings (1)

1. [P1] lint-staged 17 requires Node ≥22.22.1 but the repo supports Node ≥20.12.0 — package.json:28

Sources: Verifier, Architect, Pattern, Judge-verified

The newly-pinned versions in pnpm-lock.yaml:

lint-staged@17.0.8:
  engines: {node: '>=22.22.1'}
listr2@10.2.2:            # transitive dep of lint-staged 17
  engines: {node: '>=22.13.0'}

But package.json declares (line 45):

"engines": { "node": ">=20.12.0" }

This is a real compatibility mismatch, not just a lint warning. Contributors and CI runners on Node 20.x — an officially supported version — will hit engine-check failures (or broken behavior under engine-strict) when the Husky pre-commit hook invokes lint-staged. The binding constraint is lint-staged/listr2 requiring Node 22; the related transitive bumps (cli-truncate@5.2.0, @csstools/*) are secondary.

Resolve one of two ways:

• Keep Node 20 support: pin back to the 15.x line (lint-staged@^15.5.2, supports Node 18+) or the newest release still compatible with Node 20, and regenerate pnpm-lock.yaml.
• Drop Node 20 support (if intentional): bump engines.node to >=22.22.1 in the root package.json and the nested packages/cli/package.json (which carries its own engines block), align .nvmrc / Volta / CI runner images and contributor docs, and call out the policy change in the PR description.

(Rated P1 rather than P0: this breaks dev/CI tooling for Node 20 users, but is a recoverable local-tooling failure with a clear workaround rather than a production/runtime defect.)

---

Generated by Operon Ensemble Code Review.