Why pnpm's content addressable store contain it's package metadata?

[RookieAND]

Hello, I'm a developer currently using pnpm.
I have a question regarding pnpm's Content Addressable Store (CAS) that came up during my analysis.

When using pnpm store path to inspect the CAS, I noticed that the store contains metadata of packages hashed in HEX rather than the actual package contents.
I'm curious as to why pnpm stores it's metadata instead of the package contents.

{
  "name": "encodeurl",
  "version": "1.0.2",
  "requiresBuild": false,
  "files": {
    "package.json": {
      "checkedAt": 1731307130492,
      "integrity": "sha512-2B7l8jlEk6X5ORjsrmWB+C7lKfu9JX4NwQ6mjwnDnQ0Z46aw6VYOsSUNiKmx9ZHWRp8oQEQQsWtYDL4XnjfaDw==",
      "mode": 438,
      "size": 1091
    },
    "README.md": {
      "checkedAt": 1731307130492,
      "integrity": "sha512-A2UJJl0UoT0nEyg3PZlty53a7HxuhDfccOKCzI9QAIwuSt3ttutkRxccsjhRNQT3MtlgrKPtlzuT98uAop5KsQ==",
      "mode": 438,
      "size": 3855
    },
    "LICENSE": {
      "checkedAt": 1731307130492,
      "integrity": "sha512-dFopY1mmM4PKVCEb5BHg1vYZE7GEmzJMaZYbPr7EDE4srhZsXjX+FK6S0StWxUcrIiKSEfiK+tiHQQpjicbhyA==",
      "mode": 438,
      "size": 1089
    },
    "index.js": {
      "checkedAt": 1731307130494,
      "integrity": "sha512-jbXZqTjzl8Ecdcd8DL5utgnF1PgaWQ8iEWP+MpHNDLKmKGuok1yPjP2r7Oyffkmlv6g23Hd+k2Jx++Da6nQU5g==",
      "mode": 438,
      "size": 1586
    },
    "HISTORY.md": {
      "checkedAt": 1731307130495,
      "integrity": "sha512-FCKolhNCBfc/1Qw/EM5cywrZjSlM24pviUTSdwts3137qroHJSn5utVv0CAtEw8Fkuf9WvB03As9EFkXOqHPpw==",
      "mode": 438,
      "size": 238
    }
  }
}

[zkochan]

This is an index file that maps the files of a package. Each individual file is stored in the content-addressable store and can be found by converting the integrity to HEX, where the first 2 chars of the hex are the subdirectory inside the store.

[RookieAND]

Oh, I see! Now I understand. Thank you for your answer!

if you don’t mind, Can I ask one more question?
I checked the index file in CAS to obtain the integrity value for the index.js file.

After converting it to HEX, I looked up the inode of the index.js file stored within CAS.
However, the inode of the index.js file in the module saved in the Virtual Store was different.

Do you know why this might be happening?
If I’ve made any incorrect assumptions, please feel free to let me know.

e.g) cookie@0.7.1

The result of converting the dist.integrity value of the package at https://registry.npmjs.org/cookie/0.7.1 to HEX is e839c89e9c7b489d802b7f824d413f64cd2f59351ba1909e831842db1888c9d1d1f6336e4c001206b7c4a4786218e670fe75f9d5b1ede98425f23b06a38cbfd3 .

Based on this, I retrieved the package index file and checked the following JSON:

{
  "name": "cookie",
  "version": "0.7.1",
  "requiresBuild": false,
  "files": {
    "LICENSE": {
      "checkedAt": 1731377987152,
      "integrity": "sha512-Scr4piRfVq7q+vQQBTpyWGusX5lDBTzo+GtrnyDcyNnVU8Xu2mkHXKKVHU+knl9ox1PB8G3VVpgjBzU0eBh8EA==",
      "mode": 420,
      "size": 1175
    },
    "index.js": {
      "checkedAt": 1731377987152,
      "integrity": "sha512-dLZUX8QxZ/pvnpr8vclSdv6OiouJOYdcZ2A5ND4K2Fv03AKVZ0J/L1Tv6V+ikdvIUH16d8MMZc/4grpa/Pm0PA==",
      "mode": 420,
      "size": 8103
    },
    "package.json": {
      "checkedAt": 1731377987153,
      "integrity": "sha512-28LYzZyC0XTKxEhj/Xb8irIN4LjExPS25v/FsbtaaZOi7WyNnE9bLUdufkuJNwGbW7veF1552mnfnbPWZ6pTXg==",
      "mode": 420,
      "size": 1092
    },
    // ...
  }
}

From this, I converted the integrity value of index.js to HEX and verified that the file located at the path corresponds to the index.js file of the cookie@0.7.1 package.

• File Integrity : sha512-dLZUX8QxZ/pvnpr8vclSdv6OiouJOYdcZ2A5ND4K2Fv03AKVZ0J/L1Tv6V+ikdvIUH16d8MMZc/4grpa/Pm0PA==
• Convert to HEX : 74b6545fc43167fa6f9e9afcbdc95276fe8e8a8b8939875c676039343e0ad85bf4dc029567427f2f54efe95fa291dbc8507d7a77c30c65cff882ba5afcf9b43c

However, I found that the inode value of the file stored in CAS differs from the inode value in the Virtual Store (node_modules/.pnpm/cookie@0.7.1/node_modules/cookie/index.js).

I'm not sure why this is happening. Since it's a hard link, shouldn't the inodes be the same?

[zkochan]

That is because your file system supports copy-on-write. In this case, pnpm clones the files instead of creating hard links.

[RookieAND]

Oh, I see! Since macOS supports copy-on-write, that makes sense!
I'm really happy to learn how pnpm manages packages.
Thanks for the kind response :)