Repository navigation
process.versions does not list all bundled dependencies #45260
Description
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
Activity
anonrig commentedon Nov 1, 2022
For contributors looking for where to start; the versions are included in
src/node_metadata.ccXstoudi commentedon Nov 1, 2022
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 (likebase64)?targos commentedon Nov 2, 2022
For
acornandundici, thepackage.jsonis 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 commentedon Nov 2, 2022
The other concern is the policy regarding update of deps.
For example right now
base64is pointing to this commit:aklomp/base64@dc6a41c
and it implies that the CMakeList shows
0.4.0while the the next commit (aklomp/base64@9ae5ad3) is only bumping the version to0.5.0. That means that node.js is shipping a0.5.0version that hides under0.4.0.nitesh-chowdhary commentedon Nov 2, 2022
Trott commentedon Nov 2, 2022
debadree25 commentedon Nov 21, 2022
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 commentedon Nov 24, 2022
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-uvwasioption, then it's reasonable to add aprocess.version.uvwasikey for debugging purposes.Likewise, a hypothetical
--disable-histogramshould be reflected.But things that are hidden and immutable? No point in listing them.
jasnell commentedon Nov 24, 2022
From a functional perspective, perhaps. However, when producing something like an SBOM, it's important detail that should be included.
bnoordhuis commentedon Nov 24, 2022
Not sure I follow. Can you give an example when that's relevant? SBOM = Source Bill Of Materials?
jasnell commentedon Nov 24, 2022
SBOM == Software Bill of Materials. See background info here: https://www.ntia.gov/SBOM
To be certain, the
process.versionsby 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.
10 remaining items
src: add undici and acorn to `process.versions`
src: add uvwasi version
src: add uvwasi version
src: add undici and acorn to `process.versions`
src: add undici and acorn to `process.versions`
src: add cjs_module_lexer_version base64_version
src: add cjs_module_lexer_version base64_version
src: add cjs_module_lexer_version base64_version
src: add cjs_module_lexer_version base64_version
src: add cjs_module_lexer_version base64_version
src: add cjs_module_lexer_version base64_version
src: add undici and acorn to `process.versions`