process.versions does not list all bundled dependencies

[jasnell]

The process. Versions API lists the versions of vendored dependencies that are bundled into Node.js. Unfortunately, it only shows a subset. Notably missing from the list are:

• deps/acorn
• deps/base64
• deps/cjs-module-lexer
• deps/histogram
• deps/undici
• deps/uvwasi

[anonrig]

For contributors looking for where to start; the versions are included in src/node_metadata.cc

[Xstoudi]

Is this possible to give indications about how to get version of full-js libs (like acorn) or libs that doesn't expose their version number (like base64)?

[targos]

For acorn and undici, the package.json is in the source tree and contains the version number. I'll let someone else suggest a good way to expose it to our C++ code.

[Xstoudi]

The other concern is the policy regarding update of deps.
For example right now base64 is pointing to this commit:
aklomp/base64@dc6a41c
and it implies that the CMakeList shows 0.4.0 while the the next commit (aklomp/base64@9ae5ad3) is only bumping the version to 0.5.0. That means that node.js is shipping a 0.5.0 version that hides under 0.4.0.

[nitesh-chowdhary]

I would like to work on this issue.

[Trott]

I would like to work on this issue.

Thanks, but also, please, no cookie-licking.

If you'd like to work on it, please go for it and open a pull request. But don't expect this to be set aside as the thing you and only you can do.

One thing I would recommend is starting small. Open a pull request that adds just one of the missing dependencies. Good luck! If you run into trouble, a good place to ask questions about Node.js core development is the soon-to-be-renamed-to-something-better #nodejs-dev channel in the OpenJS Slack.

[debadree25]

Would parsing the package.json for all js libraries and then including them be a good idea? put quite some thought into it this is the only one that came to my mind from my limited knowledge, would love to know about any other possible way of including this in cpp code

[bnoordhuis]

Let me push back on this a little. I don't think it's necessary to list version numbers for "static" dependencies (things that are always built into the binary and never linked dynamically) because those are:

a) fixed, and

b) implementation details that aren't relevant most of the time

When the configure script grows e.g. a --shared-uvwasi option, then it's reasonable to add a process.version.uvwasi key for debugging purposes.

Likewise, a hypothetical --disable-histogram should be reflected.

But things that are hidden and immutable? No point in listing them.

[jasnell]

From a functional perspective, perhaps. However, when producing something like an SBOM, it's important detail that should be included.

[bnoordhuis]

Not sure I follow. Can you give an example when that's relevant? SBOM = Source Bill Of Materials?