Repository navigation
Remove yarn check - #106
Conversation
|
@arcanis our current use case for Things we considered:
How do you guys typically handle this scenario? cc @betaorbust |
Right now we simply make our development server restart (and run I think the solution will eventually be in the form of the project-local cache folder. It's currently a work in progress (which will probably be shipped as an experimental feature early next year), but the idea I'm working on is to make Yarn a development-only tool: you wouldn't need to run it at all on production / CI. In fact, you wouldn't have to run it at all except when running In order to do this, the cache folder (that would be reworked to only contain zip files) along with the |
In CocoaPods we solved this by having a manifest of what got installed inside the dependencies directory that CocoaPods would check for and compare to the lockfile in the project during a build. In the case of Yarn when running a command through |
|
|
||
| ## 2. Detailed Design | ||
|
|
||
| We'll remove the `yarn check` command in Yarn 2.0. |
There was a problem hiding this comment.
As well as yarn install --check-files, I assume?
There was a problem hiding this comment.
So --check-files is a bit different - it doesn't actually check 😅
It has to do with the way we make an early bailout if the node_modules is already there (to avoid running an installation if there is no need). Without --check-files Yarn will only checks for the various folders to exist (plus various other settings), whereas with --check-files it will also check for all the registered files to exist. It's not super useful anymore, but it's not as redundant as yarn check.
There was a problem hiding this comment.
Oh, I see. That’s unfortunate, I like the integrity check of —check-files, but for most people I can see checking of the expected directories exist is probably enough.
|
At Artsy we’ve been telling everybody to run |
|
|
||
| ## 4. Drawbacks | ||
|
|
||
| - The one use of `yarn check` is to provide debug information when installs aren't properly made. In practice it's never used this way, even by maintainers. |
There was a problem hiding this comment.
Ha true, it'd point out any glaring issues but I'd agree the results aren't reliable at all, esp with workspaces and resolutions
|
Why isn't this mentioned anywhere on the website or in the yarn repo for 1.x? A little frustrated as we lost a day to this and had to do some sizable reverts. |
They have been deprecated by yarn: yarnpkg/rfcs#106
|
Hello, I would like to add a I read the page at https://yarnpkg.com/en/docs/cli/check, and found this issue. But it looks like Also I'm trying to get some other warnings/errors to show up with a CLI flag, but it seems like I need to run: I would like to check for all of these warnings and errors in my CI builds, and fail the build if there are any problems with my |
依赖图零变化：迁移前后 node_modules 里唯一 name@version 都是 1526 个，逐条 diff 完全一致。实例数 1568 → 1565，少的 3 个是 Berry 把 @babel/generator、 @types/d3-timer 等重复副本去重上提，同一版本换了摆放位置，不是版本变动。 门禁：67/67 行为 spec 通过；语义差分 4914 key（基线 4916，无新增，去重反而消掉 2 条）。 不用 PnP。理由不是保守，是三条会当场断的具体依赖，写在 .yarnrc.yml 里： scripts/*.js 全以 `node ./xxx` 调用（PnP 下必须 `yarn node`）、@ant-design/cli 按 node_modules 布局找包、排障要能直接读 node_modules/antd/es/**（antd 6 迁移 里 showSearch 传对象=强制开搜索、Select 的 CSS 变量来源都是这么查出来的）。 ── yarn check 的替代（本次的主要工作量）──────────────────────────────── yarn 2 删掉了 `yarn check`（yarnpkg/rfcs#106，2019-02-18 合入），pre-push 里那条 node_modules 一致性预检失去依据。那条预检不是装饰，钩子注释记着它栽过三次，最近 一次 2026-09-11 吐出 131 条指向业务文件的假类型错。所以补 scripts/install-stamp.js： 安装时把「依赖声明 + yarn.lock」的 sha256 落到 node_modules/.install-stamp.json， push 前比对。 能力不缩水，有依据：读 yarn 1 的 lib/cli.js 可确认 InstallationIntegrityChecker.check() 比对的就是 .yarn-integrity 这个 JSON，最后只 判断 node_modules 这个【目录】在不在，从不逐包走盘（走盘的是另一个开关 --check-files，而 --integrity 明确把它从比对里过滤掉）。 反过来还更好：不再需要 yarn 在 PATH 上，只要 node——而 node 本来就是其余门禁的前提。 5 个反例验证过：改依赖版本/改 resolutions/改 lock 都拦下，只改 scripts/version 不误报， 戳缺失时给警告而不是拦。 ── 戳为什么挂插件而不是 postinstall（踩过的坑）──────────────────────── 先用的 postinstall，实测有死局：Berry 按依赖树哈希缓存 build 结果，树没变就不重跑 workspace 的 postinstall。于是改了 package.json（如 "antd": "6.6.3" → "^6.6.3"， 解析结果同版本但 lock 内容变了）→ 指纹变 → 门禁喊"跑 yarn install" → 跑了 → yarn 判定无需 rebuild、不执行 postinstall → 戳还是旧的 → 继续喊。一个永远过不去、提示还 是错的门禁比没有更糟：它教会所有人用 --no-verify，把行为门禁和类型门禁一起带走。 改用官方的 afterAllInstalled 钩子（.yarn/plugins/install-stamp.cjs），不参与 build 缓存，每次 install 必跑。已验证：同样条件下戳正常刷新，死局解除。 ── 迁移工具动过、但没说的两处 ───────────────────────────────────────── 1. 静默删掉 resolutions 里的 "mermaid/**/d3-color": "3.1.0"，日志一个字没有。原因是 Berry 的 resolutions 只支持一层嵌套，不认 ** 跨层 glob。结论是不用补，但依据不是 "反正版本没变"：树里 d3-color 只有 `1 - 3` 和 `3` 两个 descriptor，都封顶在 4 以下， 未来也漂不出 3.x，这条 pin 自始至终是空操作（跟 .yarnrc 一样是 7.4.0 上游带进来的）。 2. 自动写入两条 v1 兼容垫片，均已删除并记在 .yarnrc.yml： - approvedGitRepositories: ["**"] —— 本仓 git/github 协议依赖 0 条，这条不解决任何 问题，只是把"任意 git 仓库都能当依赖装进来"的口子敞开。 - npmMinimalAgeGate: 0 —— 关掉 Yarn 4 的供应链防护（默认 1440 分钟，即拒绝安装发布 不足 24h 的版本；npm 包被投毒后的攻击窗口正是头几小时）。本仓是全公司 OA 的部署源， 依赖升级一向显式逐个走，等一天不影响节奏，恢复默认。 教训：yarn 迁移会不告而删自己看不懂的配置，迁完必须逐条对账，不能只看 install 报没报错。 其它：.yarnrc(ignore-engines) 删除，Berry 无此开关也不需要（engines 不满足只警告不 失败，且 node 26 满足树里全部 717 条 engines.node）；engines.yarn 1.22.22 → >=4.18.0； packageManager 补回 corepack 完整性哈希（yarn set version 默认不写，是 set version 的 一次静默降级）；.gitignore 用白名单收 .yarn/，只提交 plugins，1.7MB 的 install-state.gz 不进仓库。 验证：yarn install exit 0 → webpack Compiled successfully in 22.96s，0 error， :30001 HTTP 301 正常。16 条 resolutions 逐条核对全部生效。
Cf document for motivations; in short this command is of little to no use to us, but contributes to our users being confused by its buggy behavior.