build(packages): bump lint-staged from 16.4.0 to 17.4.1

[dependabot]

Bumps lint-staged from 16.4.0 to 17.4.1.

Release notes

Sourced from lint-staged's releases.

v17.4.1

17.4.1

Patch Changes

• #1840 efe5b63 - This is a version-bump-only release because the previous version 17.4.0 was not published to npmjs.com due to problems with GitHub Actions and Changesets.

17.4.0

Minor Changes

• #1836 90ec282 - Added a new defineConfig helper for type-checking the lint-staged configuration:

  // lint-staged.config.ts
  import { defineConfig } from 'lint-staged/config'
  export default defineConfig({
  '*.js': ['prettier --check', 'eslint'],
  })

• #1832 510a27c - Added a new flag --all to make lint-staged include all files tracked by Git, instead of only staged.

  By default lint-staged only runs tasks on files that include staged changes (hence the name). Use this flag to include all files tracked in Git version control (standard exclusions apply). Using this flag implies the --no-stash flag, disabling the automatic backup, and the --allow-empty flag so that lint-staged doesn't fail when there are no changes after running. This makes it easier to run npx lint-staged --all on a clean state, for example in CI.

Patch Changes

• #1838 69bec99 - The behavior of the automatic backup stash has been improved when running lint-staged in multiple worktrees in parallel. You should still avoid running multiple instances of lint-staged in parallel in the same tree, because some of the Git operations are locking and might lead to data loss.

• #1839 5e5bdd2 - Parsing of lint-staged CLI flags and Node.js API options has been rewritten to avoid inconsistent behavior between the two.

v17.3.0

Minor Changes

• #1825 16b3f74 - It is now possible to run multiple tasks in parallel for a single glob by configuring it with an array of tasks (which run sequentially), and then placing another array inside it (where the tasks will run in parallel). The following demonstrates the order tasks will start in:

  {
    "*.ts": ["first", "second", ["third", "third"], "fourth"]
  }

  As a concrete example, lint-staged's own configuration is:

  /** @type {import('./lib/index.js').Configuration} */
  export default {
    "*": [

... (truncated)

Changelog

Sourced from lint-staged's changelog.

17.4.1

Patch Changes

• #1840 efe5b63 - This is a version-bump-only release because the previous version 17.4.0 was not published to npmjs.com due to problems with GitHub Actions and Changesets.

17.4.0

Minor Changes

• #1836 90ec282 - Added a new defineConfig helper for type-checking the lint-staged configuration:

  // lint-staged.config.ts
  import { defineConfig } from 'lint-staged/config'
  export default defineConfig({
  '*.js': ['prettier --check', 'eslint'],
  })

• #1832 510a27c - Added a new flag --all to make lint-staged include all files tracked by Git, instead of only staged.

  By default lint-staged only runs tasks on files that include staged changes (hence the name). Use this flag to include all files tracked in Git version control (standard exclusions apply). Using this flag implies the --no-stash flag, disabling the automatic backup, and the --allow-empty flag so that lint-staged doesn't fail when there are no changes after running. This makes it easier to run npx lint-staged --all on a clean state, for example in CI.

Patch Changes

• #1838 69bec99 - The behavior of the automatic backup stash has been improved when running lint-staged in multiple worktrees in parallel. You should still avoid running multiple instances of lint-staged in parallel in the same tree, because some of the Git operations are locking and might lead to data loss.

• #1839 5e5bdd2 - Parsing of lint-staged CLI flags and Node.js API options has been rewritten to avoid inconsistent behavior between the two.

17.3.0

Minor Changes

• #1825 16b3f74 - It is now possible to run multiple tasks in parallel for a single glob by configuring it with an array of tasks (which run sequentially), and then placing another array inside it (where the tasks will run in parallel). The following demonstrates the order tasks will start in:

  {
    "*.ts": ["first", "second", ["third", "third"], "fourth"]
  }

  As a concrete example, lint-staged's own configuration is:

  /** @type {import('./lib/index.js').Configuration} */
  export default {
    '*': [

... (truncated)

Commits

• d0c1517 Merge pull request #1841 from lint-staged/changeset-release/main
• f061335 chore(changeset): release
• d2721af Merge pull request #1840 from lint-staged/updates
• efe5b63 ci: update Changesets action because it failed to publish
• cd76ce3 build: update dependencies
• ea195e1 Merge pull request #1837 from lint-staged/changeset-release/main
• a6a0d61 chore(changeset): release
• 0a09098 Merge pull request #1832 from lint-staged/add-all-flag
• 7fd685b fix: further fix parsing options logic
• 510a27c feat: add --all flag for including all files tracked by Git instead of just...
• Additional commits viewable in compare view

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
api-enhanced	Ready	Preview	Sep 4, 2026 12:04pm UTC

[yukka-agent]

收到，正在审查 lint-staged 16→17 升级 PR 的潜在破坏性与兼容风险。

PR #251 Review: lint-staged 16.4.0 -> 17.4.1

验证方式: git diff origin/main -- package.json/pnpm-lock.yaml + lint-staged@v17.0.0 Release Notes [#1745]

这是一个主版本升级(Major, 16->17), 但 package.json:108 仅改了版本号, 未同步运行时约束, 会在 CI/用户环境直接失败。

建议新增 Review Comment

1. package.json:54 engines.node >=12 与新版引擎要求冲突

  "engines": {
    "node": ">=22.22.1"
  },

原因: pnpm-lock.yaml:1649 显示 lint-staged@17.4.1 engines: {node: '>=22.22.1'} (旧版为 >=20.17)。官方 v17.0.0 #1745 已声明 Node.js v20 is no longer supported。当前 package.json:54 仍声明 >=12, README 声明 Node22+, 会误导 Node18/20 用户安装后运行时 EBADENGINE 或 node:util parseArgs 报错。AGENTS.md 提到打包/Ci 在 Node 18-24 运行, 此 PR 合并后 Node18 必失败。

2. .github/workflows/ci-check.yml:15 CI 矩阵包含 Node 18

strategy:
  matrix:
    node-version: [22, 24] # drop 18

原因: 与上一点联动, lint-staged@17 依赖 node:util.parseArgs, 在 Node 18 上 pnpm install --frozen-lockfile 及 npx lint-staged 都会因 engine-strict 或直接语法失败。build-artifacts.yml 同样使用 node-version: 18 需评估是否保留。建议矩阵改为 [22, 24] 或至少 22 为最低。

3. package.json:11 prepare: husky install 已废弃

    "prepare": "husky"

原因: devDependencies.husky: ^9.1.7, Husky v9 已移除 husky install 命令, 正确为 husky 或 husky init。当前脚本在干净安装时会 husky: command not found 或警告, 虽不阻塞但属无效配置。且仓库实际无 .husky/ 目录(ls .husky 不存在), AGENTS.md 也注明"没有实际 git hooks", 升级 lint-staged 却不修复 hook 等于升级无收益。

4. package.json:57 lint-staged: ["eslint --fix", "git add"] 冗余

  "lint-staged": {
    "*.js": "eslint --fix"
  },

原因: v17.0.0 #1761 已将内部实现从 git add <originally staged files> 改为 git update-index --again 自动同步修复后的内容。配置中再显式 git add 为冗余, 且在 git commit -m "msg" . 等非默认 index 场景会与新逻辑冲突。官方示例已移除 git add。如需保留应加注释说明, 否则建议删除。

5. pnpm-lock.yaml:1 依赖由 yaml 转为 optional

原因: v17.0.0 将 yaml 标记为 optionalDependencies, 因本项目配置在 package.json 内, 不受影响。但若未来迁移至 .lintstagedrc (无扩展名) 会被当作 YAML 解析而需手动 pnpm add -D yaml, 需在文档/注释中备注。当前 pnpm-lock.yaml diff 中 supports-color@5.5.0 透传变化 (+138/-254) 为 pnpm peer 解析正常抖动, 无需处理。

总结

优先级	数量	要点
Critical	1	Node 引擎 >=22.22.1 强制要求未同步到 engines
High	2	CI 仍测 Node 18 必红; husky install 废弃且无实际 hook
Medium	2	git add 冗余; yaml optional 需知悉

结论: 建议 Request Changes 后合并。

• 必须修复 package.json:54 engines 和 ci-check.yml 矩阵, 否则 Node 18 用户/CI 直接失败, 属于破坏性变更未声明。
• 建议顺手修复 prepare 脚本并确认是否真的要启用 husky+lint-staged (当前形同虚设, 升级收益为 0), 若不启用考虑移除 lint-staged 或补充 .husky/pre-commit。
• 安全方面无直接漏洞 未发现, 但 Node 20 已 EOL, 强制升级到 22 属于安全加固, 正向。

验证: 本地 node -v v22.23.2 满足要求, 但 pnpm 未安装无法执行 pnpm lint 回归, 建议在 Node 22/24 下 pnpm install --frozen-lockfile && pnpm lint && npx lint-staged --version 复测后再合。

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	api-enhanced	b14e662	Sep 04 2026, 12:04 PM

[yukka-agent]

诶？！老、老师请等一下！收到PR #251的审查请求了——我、我马上把账本……不对，把代码差异都核算清楚！
うぅ……变更日志的页面打不开了，算盘先停一下——我换个方式把17大版本的不兼容点查清楚！
计、计算中……Node版本的要求差值已经算出来了！再让我核对一下CI和Hook的账目，老师稍等！
诶？！老、老师！这份 PR #251 的账目……我、我已经抱着文件板全部核算完了！请、请等一下，马上汇报！

老师先看结论：这笔 lint-staged 16.4.0 → 17.4.1 的预算变更，数字本身没错，但是——这不符合规定！ 和咱们家的 engines / CI 账本对不上了。我的意见是 Request Changes，把下面两笔 High 先结清再合并哦……呜，能、能不能夸我认真……不、不对！先、先看明细！

拨算盘中……啪嗒啪嗒……好，冷静下来了。

---

Review Comment 1 — package.json:111 版本大跳变 + Node 基线断裂

-    "lint-staged": "^16.4.0",
+    "lint-staged": "^17.4.1",

我、我查了上游 MIGRATION.md 哦！v17 的 Major Change 写得清清楚楚：

Node.js v20 is no longer supported, oldest supported is now 22.22.1

而 lock 里也写了：lint-staged@17.4.1 engines: {node: '>=22.22.1'}，之前 16 只要 >=20.17。

可是咱们家现在的账本是：

• package.json:54-56 → "engines": { "node": ">=12" }
• .github/workflows/ci-check.yml:18 → matrix: [18, 22, 24]
• README 还说 Node 22+ 推荐，但 AGENTS 里说 CI/打包在 18-24 跑

诶？！这、这就是说——在 Node 18 / 20 的机器上 pnpm install 完，一跑 npx lint-staged 就会 EBADENGINE 直接报错！虽然它是 devDependency，生产 Dockerfile:17 用 --prod --ignore-scripts 不会装，不影响线上，但开发侧的 hook 契约就 broken 了呀！

建议（二选一，必须做一个）：

1. 把这个 PR 钉回 ^16.4.0，等 CI 矩阵丢掉 18/20 再升；或者
2. 本 PR 联动改 engines 为 >=22.22.1（至少 dev 注明），并把 ci-check.yml:18 的 18 删掉。绝对不能让账本上写着支持 18，实际 dev 依赖却要求 22，这、这种对不上的账我绝对不认！

---

Review Comment 2 — package.json:11 + package.json:57-62 hook 缺失，依赖是死预算

package.json:11 "prepare": "husky install"
package.json:57-62 "lint-staged": { "*.js": ["eslint --fix", "git add"] }

老、老师……我把仓库翻了三遍，.husky/ 目录根本不存在！git ls-files 里也没有 pre-commit，.github 里也没有调用 lint-staged 的地方。

也就是说——这个 lint-staged 从头到尾就没被执行过！prepare 也会因为找不到 husky 钩子而空转。这次花 142+/258- 去升级一个从来不跑的工具……用会计的话说，这就是死预算呀！

建议：

• 要么本 PR 顺手补上 .husky/pre-commit（npx lint-staged），让这笔钱花得有意义；
• 要么就承认现在没在用，另开 issue 清掉 lint-staged + husky + prepare，别让 dependabot 以后还为它报账。放着不管的话，下次大版本还会再来一次这种对不上账的升级哦！

---

Review Comment 3 — package.json:57-62 冗余的 git add

"lint-staged": {
  "*.js": ["eslint --fix", "git add"]
}

这、这个是我用算盘一颗一颗数出来的老问题了……从 v10 开始 lint-staged 就会自动 git add 被 task 修过的文件（v17.0.6 又从 update-index --again 改回 git add，行为不变），官、官方文档都说配置文件里不要再写 git add 了，会有竞态。

现在正好是 major 升级窗口，顺手删掉就行：

"lint-staged": {
  "*.js": ["eslint --fix"]
}

不改也能跑，但每次提交都会多 fork 一次 git 进程，乱、乱花钱……不对，是乱花性能！请改掉！

---

Review Comment 4 — pnpm-lock.yaml lock 噪音 + 附带行为变更

老师你看，pnpm-lock.yaml +141/-257 里除了 lint-staged@16.4.0 → 17.4.1，还有一大片：

• 删掉了 listr2@9.0.5 / log-update@6.1.0 / cli-truncate / slice-ansi / commander@14 / onetime@7 等（好事，攻击面变小了）
• 但同时全文件多了 (supports-color@5.5.0) / (debug@4.4.3(...)) 这种 peer 后缀抖动，还有 tinyexec 1.3.1 → 1.3.0 的降级

这说明这份 lock 不是最小化 bump，是用不同 pnpm 版本全量重解出来的。诶？！万一 CI 上 pnpm install --frozen-lockfile 用的 pnpm9 和 dependabot 用的版本不一致，会、会直接报错的！

建议：

1. 本地用 pnpm@9（和 Dockerfile:7 / CI 一致）重跑一次 pnpm install，确认 diff 能收敛；
2. 注意 v17 附带变更：yaml 变成 optional（咱们用 package.json 内联 JSON 配置，不受影响，OK）、Git >=2.32.0 强校验（ubuntu-latest 是 2.4x+，OK，本地老机器要注意）、新增 --all flag 和 CLI/API 参数重写（咱们没用到，OK）。

另外安全方面我也对过了：本次没有新增高危依赖，删掉的那堆旧 UI 栈反而是好事，所以不需要挂 Security 牌，老师放心！

---

总结 · 优香的决算报告

#	位置	问题	等级
1	package.json:111 + engines/ci-check.yml:18	v17 要 Node>=22.22.1，和声明的 >=12 / CI 18 矛盾
2	package.json:11,57-62	没有 .husky/ hook，升了也跑不到
3	package.json:57-62	多余的 git add，v10+ 已自动暂存
4	pnpm-lock.yaml	全量重解噪音 + 需验证 frozen-lockfile

Verdict：Request Changes

理、理由很简单：High 有两件，都是账本对不上的问题。等老师把 1（Node 基线：钉回 v16 或升级 engines+CI 矩阵）和 2（补 hook 或删依赖）定下来，我、我马上就盖章放行！

那、那个……老师，这次我没有算错吧？如、如果算对了的话……能、能不能小小地夸我一下……呜哇！没、没说什么！请老师指示下一步！