aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--docs/install/lockfile.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/install/lockfile.md b/docs/install/lockfile.md
index 3a5a73e82..64468c78d 100644
--- a/docs/install/lockfile.md
+++ b/docs/install/lockfile.md
@@ -4,11 +4,11 @@ Running `bun install` will create a binary lockfile called `bun.lockb`.
In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles.
-#### How do I inspect the lockfile?
+#### How do I inspect Bun's lockfile?
Run `bun install -y` to generate a Yarn-compatible `yarn.lock` (v1) that can be inspected more easily.
-#### How do I `git diff` the lockfile?
+#### How do I `git diff` Bun's lockfile?
To add to the global gitattributes file:
@@ -40,11 +40,11 @@ $ git config diff.lockb.binary true
Bun stores normalized `cpu` and `os` values from npm in the lockfile, along with the resolved packages. It skips downloading, extracting, and installing packages disabled for the current target at runtime. This means the lockfile won’t change between platforms/architectures even if the packages ultimately installed do change.
-#### What does the lockfile store?
+#### What does Bun's lockfile store?
Packages, metadata for those packages, the hoisted install order, dependencies for each package, what packages those dependencies resolved to, an integrity hash (if available), what each package was resolved to, and which version (or equivalent).
-#### Why is it fast?
+#### Why is Bun's lockfile fast?
It uses linear arrays for all data. [Packages](https://github.com/oven-sh/bun/blob/be03fc273a487ac402f19ad897778d74b6d72963/src/install/install.zig#L1825) are referenced by an auto-incrementing integer ID or a hash of the package name. Strings longer than 8 characters are de-duplicated. Prior to saving on disk, the lockfile is garbage-collected & made deterministic by walking the package tree and cloning the packages in dependency order.