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.

[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?

[jasnell]

SBOM == Software Bill of Materials. See background info here: https://www.ntia.gov/SBOM

To be certain, the process.versions by itself does not provide all of the information necessary for this purpose but it helps.

Also to be clear, I'm not suggesting that this is the only reason we should provide this additional detail.

[MrJithil]

Added version info of cjs_module_lexer and base64

[MrJithil]

Pending Version Additions

• deps/acorn src: add undici and acorn to process.versions #45621
• deps/base64 src: add cjs_module_lexer_version and base64_version #45629
• deps/cjs-module-lexer src: add cjs_module_lexer_version and base64_version #45629
• deps/histogram
• deps/undici src: add undici and acorn to process.versions #45621
• deps/uvwasi src: add uvwasi version #45639

[bnoordhuis]

I've looked through the linked pull requests but the version number parsing all feels kind of fragile and ad hoc. I again question the wisdom of doing this.