Version Conflict and Diamond Report (Markdown)
The written explanation of both diamonds in this category — the one that resolves to a single shared node and the peer conflict that forces a nested duplicate — with the four assertions a resolver test should make. Every package, version, hash and licence is fictional — the tree describes nothing real.
# Version conflict report — Orchard Gateway 4.2.0 (SAMPLE)
> SAMPLE — fictional supply-chain data. Every package, registry, version, hash, licence, advisory identifier and signature in this document is invented.
## Summary
| Package | Requested by | Range | Resolved | Outcome |
| --- | --- | --- | --- | --- |
| `example-logger` | `@orchard-example/router` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `@orchard-example/http-core` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `example-metrics` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `example-cache` (peer) | `^2.9.0` | 2.9.0 | **duplicated** |
## The diamond that resolves
Three parents require `example-logger` at `^3.4.0`. All three ranges are satisfied by 3.4.1, so the resolver installs **one** copy and every parent shares it. A graph builder that emits three nodes here is wrong.
```
gateway ──┬── router ──┐
├── http-core ──┼──> example-logger 3.4.1 (one node, in-degree 3)
└── metrics ──┘
```
## The diamond that does not
`example-cache` declares a peer range of `^2.9.0`, which 3.4.1 does not satisfy. There is no single version that satisfies both `^3.4.0` and `^2.9.0`, so npm nests a second copy under the requiring package. That is the state `package-lock-peer-conflict.json` in the lockfiles subcategory encodes.
## What to assert
1. The resolved graph has **10** nodes, not 12 — repeat visits are the same node.
2. `example-logger` has an in-degree of **3** in the primary graph.
3. In the peer-conflict lockfile, `example-logger` appears at **two** versions and a duplicate report must say so.
4. Neither situation is an error on its own: one is normal deduplication, the other is a documented cost.
Specifications
- Seed
- 51200
- Sample Only
- true
- Format
- Markdown
- Diamonds
- 2
- Assertions
- 4
- Line Endings
- LF
Testing contract
Reference control- Scenario
- Turn a resolver's behaviour into assertions instead of screenshots.
- Expected result
- A correct resolver satisfies all four listed assertions: 10 nodes, in-degree 3 on example-logger, two versions in the peer-conflict lockfile, and neither case reported as a failure.
What is a .md file?
Markdown (MD) is a lightweight plain-text markup language that uses simple punctuation conventions to denote headings, lists, links, emphasis, and code. It is designed to be readable as-is and to convert cleanly to HTML. It is widely used for documentation, READMEs, and content authoring.
How to use this file
Use an example Markdown file to test parsers and renderers, verify GitHub-Flavored Markdown extensions like tables and fenced code, and exercise HTML-conversion pipelines.
How to use this file for testing
“Version Conflict and Diamond Report (Markdown)” is a deterministic Novus Examples fixture for Editor testing, Graph data, Conversion testing. Text-based files you can open, edit, and download directly in the browser editor.
Documented properties for this file: seed 51200 · LF · Markdown. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
SBOM, lockfile, provenance, and advisory fixtures describe the same fabricated component tree across formats, so a converter or scanner can be diffed against a known answer. Every package name, version, hash, and advisory ID is invented — never treat a finding here as real.
Code examples
import markdown # pip install markdown
html = markdown.markdown(open("version-conflict-report.md").read())
print(html[:200])Related files
- txtcargo tree OutputCargo's tree output, which writes versions with a leading `v` and marks already-shown subtrees with `(*)` — close enough to npm's tree to fool a parser, different enough to break one. Every package, version, hash and licence is fictional — the tree describes nothing real.
- dotDependency Graph With a Cycle (Graphviz DOT)The cyclic plugin graph as DOT, with the three cycle edges highlighted. Graphviz renders it happily, which is exactly why a topological sort must be the thing that rejects it. Every package, version, hash and licence is fictional — the tree describes nothing real.
- txtgo mod graph Edge List`go mod graph` output: a flat edge list, one `parent@version child@version` pair per line with no indentation at all — the simplest graph serialisation in this category and the easiest to diff. Every package, version, hash and licence is fictional — the tree describes nothing real.
- txtGradle dependencies Report OutputGradle's dependency report, which marks repeat subtrees with `(*)` and explains the marker in a footer — so a parser has to resolve those references back to their first occurrence. Every package, version, hash and licence is fictional — the tree describes nothing real.
- txtMaven dependency:tree OutputMaven's dependency tree, complete with the [INFO] log prefix that has to be stripped before the tree can be read and the five-part coordinate form Maven uses. Every package, version, hash and licence is fictional — the tree describes nothing real.
- jsonnpm ls Dependency Tree (JSON)The nested tree `npm ls --json` prints, where a shared dependency is REPEATED under every parent rather than deduplicated — so counting objects gives a larger number than the graph has nodes. Every package, version, hash and licence is fictional — the tree describes nothing real.
Generated by generation/supply_chain.py. Free for any use, no attribution required — license.