Return libc field in npm registry API with Accept: application/vnd.npm.install-v1+json header

[Brooooooklyn]

Select Topic Area

General

Body

Ref:

• libc field doesn't present in the lockfile pnpm/pnpm#9871 (comment)
• [BUG] libc field is missing in package-lock.json npm/cli#8514
• fix: arborist libc manifest npm/cli#7126

Currently, in order to build the correct dependencies tree, package managers either abandon checking the libc field, which causes both musl and glibc binaries to be downloaded in Linux environments.
Or they request complete metadata Accept: application/json during the fetch phase. Both approaches make installation slower and consume a lot of unnecessary traffic.

[tmilost]

Hi @Brooooooklyn

Question:
Why doesn’t the npm registry API return the "libc" field when requests use the Accept: application/vnd.npm.install-v1+json header, and how does this impact package managers?

Answer:
Currently, the npm registry API does not include the libc field in responses when using the Accept: application/vnd.npm.install-v1+json content type. The libc field helps distinguish between different C standard libraries (like glibc and musl) on Linux, which is critical for tools that install native binaries.

Implications:

• Missing Data: Without the libc field, package managers such as npm, pnpm, and others cannot reliably determine which binary to install for a user's environment.
• Workarounds: To get the libc information, tools request the full package metadata with Accept: application/json. This approach is slower and increases traffic, as the v1+json format is designed to be minimal for installation speed.
• Problems: As reported in npm/cli#8514 and pnpm/pnpm#9871, this slows down installations and can cause users to download both musl and glibc binaries, wasting bandwidth and disk space.

Possible Solutions:
The npm registry would need to include the libc field in API responses for Accept: application/vnd.npm.install-v1+json, or package managers must continue to use the less efficient full metadata endpoint.

References:

• pnpm/pnpm#9871 (comment)
• npm/cli#8514
• npm/cli#7126

---

Summary:
This is a limitation of the npm registry API design. Adding the libc field to the v1+json response would improve efficiency for package managers and users who need platform-specific binaries. Until then, package managers must fetch full metadata or risk incorrect/duplicate binary downloads.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Brooooooklyn]

Ping

[fengmk2]

Many native modules depend on this feature. Is it possible to implement it within this year?