Cache the results

[H4ad]

Most of the functions depend on functions that are expensive to call, I even opened an issue on NodeJS to talk more about it nodejs/node#48204.

So, if more than one library depends on this library and the results from it, they will call the expensive functions twice, do you see some issue with caching it?

Also, some libraries uses a faster way of checking if musl is supported, like https://github.com/swc-project/cli/blob/master/src/swcx/index.ts#L78, I don't know why they use getReport but did you see any issue with this method?

[lovell]

Hi, the response of getReport(), if available, is already cached as report.

detect-libc/lib/process.js

Lines 8 to 16 in d49b8d3

	let report = null;
	const getReport = () => {
	if (!report) {
	/* istanbul ignore next */
	report = isLinux() && process.report
	? process.report.getReport()
	: {};
	}
	return report;

The response of running the getconf ... ldd ... child process, if required, is already cached as commandOut.

detect-libc/lib/detect-libc.js

Lines 9 to 21 in d49b8d3

	const command = 'getconf GNU_LIBC_VERSION 2>&1 || true; ldd --version 2>&1 || true';
	let commandOut = '';
	const safeCommand = () => {
	if (!commandOut) {
	return new Promise((resolve) => {
	childProcess.exec(command, (err, out) => {
	commandOut = err ? ' ' : out;
	resolve(commandOut);
	});
	});
	}
	return commandOut;

The benchmark timings for the underlying getReport() in the linked issue are surprising though. Perhaps we should remove its use entirely?

[H4ad]

Oh nice, sorry for misreading the code, I will update my statement on the linked issue.

About removing the usage, I see some JS libraries that use readFileSync to check for musl, I assume can be used but I don't know is 100% safe as getReport.

The problem with readFileSync is: is just an optimistic evaluation, that file could not exist in the environment (I read it somewhere but I didn't find the source anymore).

But I also find cases in other languages where ldd is used to check for musl.

I think this could be released as a major version as we don't exactly know the potential issues, or am I being a lot safer?

[lovell]

I tested this with a few flavours of Linux and versions of Node.js and can confirm the use of fs.readFile is currently always faster than getReport(), which itself is always faster than exec-ing a child process. We're talking ~2ms vs ~4ms vs ~6ms.

However the libc version number is not always available via the readFile method so we'd need all existing methods to remain in place.

[H4ad]

So, we can optimize familly, which will speed up isNonGlibcLinuxSync and isNonGlibcLinux but there's nothing we can do to speed up when the user wants the version.
At least, those who want to check if the system is musl can get a little bit better performance.

If that's the case, I can open a PR to improve these methods.