1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
`tests/cross_validate.rs` runs dagre-rs against a baseline JSON
(`cross-validate/reference_data.json`) that was generated from a specific
upstream `dagre.js` commit. The `_meta` block at the top of that JSON is
authoritative — keep it in sync with whatever you actually ran.
`cargo test` does **not** rebuild the baseline; it deserializes the committed
JSON. You only need a working `ref/dagre-js` if you want to *regenerate* the
baseline.
The current baseline (see `_meta` in `reference_data.json`) was produced from:
- --
To regenerate against the same commit:
```bash
git clone https://github.com/dagrejs/dagre.git ref/dagre-js
cd ref/dagre-js
git checkout 4713b59bfa05af56cf58aa01e2027adf5d2dcf88
npm ci
npm run build # produces dist/dagre.esm.js
cd ../..
node cross-validate/generate_reference.mjs
```
The script reads `ref/dagre-js/package.json` and runs `git rev-parse HEAD`
inside `ref/dagre-js`, then writes the resulting version + commit into
`_meta` automatically — so the baseline always self-documents which upstream
it came from.
1. 2.3. - - -4.
`ref/dagre-js` is treated as a developer convenience, not a build dependency:
the only consumer is `generate_reference.mjs`, the JSON output is checked in,
and end users of the crate never need it. A submodule would force every
`cargo` user to fetch a JS repo for no reason. The `_meta` block + this
SETUP.md keep the version pin explicit without that cost.