process.release.headersUrl: distributors might want to provide an absolute file url

[kapouer]

In which case it wouldn't be a .tar.gz file, but a directory (for example file:///usr/include/nodejs on debian).
This would be useful for configurability of node-gyp, as explained in nodejs/node-gyp#1415.

On debian we build nodejs against potentially different versions of shared libraries required by nodejs.
Their respective headers are all available in system-installed places for gyp to discover.
Until now it didn't change anything, however it becomes problematic when building a module using openssl: node-gyp pulls the "official" nodejs 8 headers with openssl 1.0 headers, but the system-installed node has been built against openssl 1.1.

Of course, the node-gyp debian package is already patched so that it uses the right include directory.
But that doesn't prevent npm-installed modules from installing their own node-gyp version which will download the "wrong" headers.

cc-ing @nodejs/delivery-channels here again since many distributions are already using openssl 1.1.

[bnoordhuis]

That should already work if you do ./configure --release-urlbase=file:///usr/share/nodejs but node-gyp needs to be taught to recognize file paths.

(The file:// prefix might not be necessary, a leading slash should be sufficiently unambiguous.)

[kapouer]

Why i am asking here is to document those two usages:

• using a file path in headersUrl
• allowing that file path to be a directory path

Of course node-gyp needs to handle this, but maybe some other software is relying on headersUrl and will break if i start changing it. It's a breaking change !

[kapouer]

Update: it will break other software:
https://github.com/search?utf8=%E2%9C%93&q="process.release.headersUrl"&type=Code

[bnoordhuis]

Meteor is its own thing so probably not a concern.

[kapouer]

Ok, but it's still some kind of API change, isn't it ? It's a documented field.

[kapouer]

It's surely not a good idea to change the behavior of those properties as they are computed in

node/src/node.cc

Lines 3026 to 3046 in b55a11d

	#if defined(NODE_RELEASE_URLBASE)
	# define NODE_RELEASE_URLPFX NODE_RELEASE_URLBASE "v" NODE_VERSION_STRING "/"
	# define NODE_RELEASE_URLFPFX NODE_RELEASE_URLPFX "node-v" NODE_VERSION_STRING
	READONLY_PROPERTY(release,
	"sourceUrl",
	OneByteString(env->isolate(),
	NODE_RELEASE_URLFPFX ".tar.gz"));
	READONLY_PROPERTY(release,
	"headersUrl",
	OneByteString(env->isolate(),
	NODE_RELEASE_URLFPFX "-headers.tar.gz"));
	# ifdef _WIN32
	READONLY_PROPERTY(release,
	"libUrl",
	OneByteString(env->isolate(),
	strcmp(NODE_ARCH, "ia32") ? NODE_RELEASE_URLPFX "win-"
	NODE_ARCH "/node.lib"
	: NODE_RELEASE_URLPFX
	"win-x86/node.lib"));
	# endif

.
I also note there is a libUrl property for windows.
Maybe a includePath property would be more meaningful here.

[benjamn]

Just to be clear, I don't think this feature request has any positive or negative consequences for Meteor. Meteor uses official Node releases when we possibly can (unless there's a critical fix that requires a temporary custom build), so we'll be using the default process.release.headersUrl when we pre-bundle Meteor's dependencies. Meteor is a "distributor" of Node only in the (weak) sense that we bundle a specific version of Node so our developers don't have to install it independently, and so that we can (occasionally) fix Node problems that affect Meteor more urgently than the general Node developer community.

[jasnell]

There's been zero activity on this for over 2 years. It's still something that could likely be documented but given that it hasn't been picked up yet, it's unlikely. Recommend closing for now.

[jasnell]

Closing given lack of responses and activity.