bun.lock (Text Lockfile)
Bun's text lockfile, where each package is a positional array of descriptor, dependency map and integrity string rather than an object — a shape that breaks parsers assuming every lock entry is keyed. Every package, version, hash and licence is fictional — the tree describes nothing real.
{
"lockfileVersion": 1,
"workspaces": {
"": {
"name": "orchard-gateway",
"dependencies": {
"@orchard-example/router": "^2.1.0",
"@orchard-example/http-core": "^1.8.0",
"example-metrics": "^4.0.0",
"example-cache": "^0.9.0",
"example-crypto-shim": "^1.2.0"
}
}
},
"packages": {
"@orchard-example/router": [
"@orchard-example/router@2.1.3",
{
"example-logger": "^3.4.0",
"example-retry": "^1.0.0"
},
"sha512-qtnM4l9j8zUuqQ9ICsxCdfl879PtducHYPiqO151qEu6bBv48+zuYbTbn/vSTJGbCd2RvGpDry/NEkSe1babaA=="
],
"@orchard-example/http-core": [
"@orchard-example/http-core@1.8.0",
{
"example-logger": "^3.4.0",
"example-json-path": "^2.0.0"
},
"sha512-fG9AJmG+37+sln/eMVPmbu/bIcV+QbJ3bibSV9ob8PV6GYNFinrhSJQYFxkEYEHxckXBn7ExDim59rqSDaYoFg=="
],
"example-metrics": [
"example-metrics@4.0.0",
{
"example-logger": "^3.4.0"
},
"sha512-Sq3cxZ+Brv4bgLd+5B/o3upQ1O6YKjbr6TP5ZBZfw4XVjna6/8YkOeB52iLhrRDjs1UiF5v20Ijr7bEJtHKcOQ=="
],
"example-cache": [
"example-cache@0.9.2",
{
"example-yaml-lite": "^1.1.0"
},
"sha512-AfwdCZmLEAUsc7Xx0ze+X4cSz6ES8G63hh3Jwx7mHEBJUNpzRLZBq7fDYVk7+cVh9spu+3wey8a0VDJS6cEpTw=="
],
"example-crypto-shim": [
"example-crypto-shim@1.2.0",
{},
"sha512-C9iqJP6f/S7V/NsRGHnVv/u2nPtnjFMJbs4p8tMbjRSxrHeEjl6APolSniPvMFH0jlDUuO06nb86/a/GDEWRKg=="
],Specifications
- Seed
- 51200
- Sample Only
- true
- Ecosystem
- Bun
- Lockfile Version
- 1
- Packages
- 9
- Entry Shape
- [descriptor, deps, integrity]
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Parse a lockfile whose package entries are positional arrays.
- Expected result
- All 9 entries yield a descriptor, a dependency map (empty for leaves) and a sha512 integrity string read from index 2, not from a named field.
What is a .lock file?
A .lock file pins the exact dependency graph a package manager resolved, so a later install reproduces it byte for byte. Cargo.lock and Poetry's poetry.lock use TOML, Gemfile.lock and yarn.lock use their own line-oriented grammars, and all of them record resolved versions, source registries, integrity hashes, and the transitive edges between packages. It is committed alongside the human-edited manifest, which states ranges rather than exact versions.
How to use this file
Use an example .lock file to test dependency parsers, SBOM generators, and vulnerability scanners, verifying that transitive dependencies and integrity hashes are read correctly and that a pinned version is never confused with the range declared in the manifest.
How to use this file for testing
“bun.lock (Text Lockfile)” is a deterministic Novus Examples fixture for JSON parsing, Config parsing, Conversion testing. Flat, deeply nested, JSON Lines, and intentionally invalid JSON for testing parsers and error handling.
Documented properties for this file: seed 51200 · LF. 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.
Feed the file to your parser and assert it handles the documented quirks — quoted delimiters, embedded newlines, ragged rows, or invalid syntax; the valid↔invalid distinction is labelled in the title.
Related files
- lockCargo.lock (version 3, Legacy)The same fictional Rust tree pinned by a version 3 Cargo.lock, for testing that a reader keys on the declared version rather than assuming the newest format. Every package, version, hash and licence is fictional — the tree describes nothing real.

- lockCargo.lock (version 4)A Rust Cargo.lock in the version 4 format — TOML [[package]] tables with a registry source, a sha256-shaped checksum and a name-only dependencies array that resolves against the other tables. Every package, version, hash and licence is fictional — the tree describes nothing real.

- jsonnpm package-lock.json (lockfileVersion 1, Legacy)The original npm v1 lockfile layout — a nested dependencies object with requires maps and no packages section — still found in long-lived repositories and needed by any migration path. Every package, version, hash and licence is fictional — the tree describes nothing real.

- jsonnpm package-lock.json (lockfileVersion 2, Dual Layout)The transitional npm v2 lockfile, which carries BOTH the v3 packages map and the legacy nested dependencies tree describing the same fictional install — the case where a parser must not double-count. Every package, version, hash and licence is fictional — the tree describes nothing real.

- jsonnpm package-lock.json (lockfileVersion 3)An npm lockfile in the modern v3 layout: a flat packages map keyed by node_modules path, with resolved tarball URLs and sha512 subresource integrity for nine fictional dependencies. Every package, version, hash and licence is fictional — the tree describes nothing real.

- jsonnpm-shrinkwrap.json (Publishable Lock)The shrinkwrap variant of an npm lockfile — identical in structure to package-lock.json but published inside the package tarball, so tooling that keys on the filename must handle both. 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.