记录npmjest-haste-map
兼容性立方体
任选两个维度作为坐标轴，其余维度都成为筛选条件。点击单元格会固定这一切片，并向下钻取一层。
22026-08-30
如何阅读网格
如何阅读单元格： 数字是该比率所依据的已记录观测次数——一次构建每到达一个阶段就留下一条观测，因此它既不是构建数，也不是机器数或人数。旁边的文档是另一个来源不同的事实：该坐标是否有样例，以及我们在那里运行它的结果。
- 该坐标还没有样例
- 有样例 — 我们尚未在该坐标运行过它
- 有样例 — 我们在该坐标运行过，并且干净地结束
- 有样例 — 我们在该坐标运行过，并且失败了
- 有样例 — 该坐标同时记录了通过的和失败的运行
- 没有记录 — 未知，既非“可用”也非“损坏”
- 这一格下面还有层级 — 点击打开
有文档，就说明该坐标有样例。样例是否存在，是关于这个版本和这个 API 的事实，不随操作系统、运行时或包管理器改变；颜色说的是它在你正在看的那个环境里跑得怎么样。
单元格是此切片中仍在变化的所有维度的汇总（n/m 计数标明其范围）。点击即可固定其坐标并查看下一层。
依赖
| 库 | 版本 | 在那里测得 | 项目 |
|---|---|---|---|
| @jest/types | 29.6.3 | 契约通过 | 8 个项目日 |
| @types/graceful-fs | 4.1.9 | 契约通过 | 5 个项目日 |
| @types/node | 26.2.0 | 契约通过 | 1 个项目日 |
| @types/node | 26.3.0 | 契约通过 | 2 个项目日 |
| @types/node | 26.4.0 | 契约通过 | 3 个项目日 |
| anymatch | 3.1.3 | 契约通过 | 5 个项目日 |
| fb-watchman | 2.0.2 | 契约通过 | 5 个项目日 |
| graceful-fs | 4.2.11 | 契约通过 | 8 个项目日 |
| jest-regex-util | 29.6.3 | 契约通过 | 8 个项目日 |
| jest-util | 29.7.0 | 契约通过 | 8 个项目日 |
| jest-worker | 29.7.0 | 契约通过 | 5 个项目日 |
| micromatch | 4.0.8 | 契约通过 | 7 个项目日 |
| walker | 1.0.8 | 契约通过 | 5 个项目日 |
测量列说的是每个依赖自身版本的情况，而不是这一对的情况。解析器把两个版本放在一起，并不证明它们能协同工作。
各版本的依赖版本
本包的每个版本把子依赖解析到了哪个版本。版本发生变动的子依赖排在最前：升级正是在那里改变了你脚下的东西。
| 库 | 30.4.1 | 29.7.0 |
|---|---|---|
| @jest/types | 30.4.1 | 29.6.3 |
| @types/node | 26.4.0 | 26.2.0 |
| jest-regex-util | 30.4.0 | 29.6.3 |
| jest-util | 30.4.1 | 29.7.0 |
| jest-worker | 30.4.1 | 29.7.0 |
| @types/graceful-fs | — | 4.1.9 |
| anymatch | 3.1.3 | 3.1.3 |
| fb-watchman | 2.0.2 | 2.0.2 |
| graceful-fs | 4.2.11 | 4.2.11 |
| micromatch | — | 4.0.8 |
| picomatch | 4.0.7 | — |
| walker | 1.0.8 | 1.0.8 |
发生变动：5 · 所有版本相同：7
一条边记录的是解析器在真实机器上把一个版本放在了另一个版本旁边。它并不主张两者能协同工作；那个问题由样本和契约回答，而不是由这里存在一行来回答。