Is http(s)_proxy supported?

[audetto]

Hi

I am behind a proxy and I cannot get started with cmake-js build

What I get is

info TOOL Using Ninja generator, because ninja is available.
info DIST Downloading distribution files to: /home/user/.cmake-js/node-x64/v19.0.1
http DIST       - https://nodejs.org/dist/v19.0.1/SHASUMS256.txt
ERR! OMG Request failed with status code 400
ERR! OMG Request failed with status code 400

Note that the proxy is set up properly because wget can download the file with no problems

user@GBMACVCSW2689:~/projects/naf$ wget https://nodejs.org/dist/v19.0.1/SHASUMS256.txt
--2022-12-31 13:39:14-- https://nodejs.org/dist/v19.0.1/SHASUMS256.txt
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘SHASUMS256.txt.1’
 
SHASUMS256.txt.1                            [ <=>                                                                            ]   3.05K  --.-KB/s    in 0s     
 
2022-12-31 13:39:14 (439 MB/s) - ‘SHASUMS256.txt.1’ saved [3127]

[audetto]

If you have come here, the answer is no.
Problem in axios, see #185

[Julusian]

Maybe you can manage with the 'offline mode' #260?

I will happily accept a PR that changes axios out for another http client that does support proxies. I have not seen a http proxy in many years, so have no way of testing a potential implementation myself.
Maybe using https://www.npmjs.com/package/got or https://www.npmjs.com/package/node-fetch would allow for this?

[audetto]

Answer does not seems obvious: request/request#3143

[audetto]

Maybe you can manage with the 'offline mode' #260?

Probably, but the PR does not really give any example.
It talks about "runtime-directory", "cmake-js-custom-dir", "nodedir", "internalPath" without telling what they are, or how I should populate them.

If I understand, some other tool will download the header files, and I just tell cmake-js where they are.
But how do I do it exactly?

[Julusian]

Probably, but the PR does not really give any example.
It talks about "runtime-directory", "cmake-js-custom-dir", "nodedir", "internalPath" without telling what they are, or how I should populate them.

If I understand, some other tool will download the header files, and I just tell cmake-js where they are.
But how do I do it exactly?

That PR predates my involvement in the project, so I can't really add much more than is in that PR.

From a quick run to see what it downloads, it looks like it is for me creating ~/.cmake-js/node-x64/v16.16.0/include based on downloading and extracting https://nodejs.org/dist/v16.16.0/node-v16.16.0-headers.tar.gz.

Another option to consider is that if you are using cmake-js v7, if you can make your project be node-api based instead of nan based, then it won't need to download any headers.

[audetto]

Hi

I have tried again to use cmake-js, but unfortunately it is still unclear how to make it work behind a proxy.

Another option to consider is that if you are using cmake-js v7, if you can make your project be node-api based instead of nan based, then it won't need to download any headers.

I am using 7.2.1 and my project is node-api based, still cmake-js tries to donwload https://nodejs.org/dist/v21.1.0/SHASUMS256.txt

Maybe I did not tell it that my project is indeed node-api based. How do I do it?

In the .nvm folders there are already all header files, why does it need more?

[Julusian]

Maybe I did not tell it that my project is indeed node-api based. How do I do it?

I appear to have not documented that in the readme, only the release notes for 7.0

Add this to your package.json, with the correct napi_version value.

"binary": {
    "napi_versions": [7]
  },

I feel like I should redo how this 'detection' works, but need a strategy for figuring it out. Perhaps the presence of node-addon-api should be considered?

[Julusian]

In the .nvm folders there are already all header files, why does it need more?

Its a case of not knowing where to find them, and the paths varying by platform and by version manager, with no guarantee of finding them. Last time I checked node-gyp (the official module build tool) it was always performing downloading, so I am not aware of any prior art we can learn from.

As this downloading is only needed for non node-api modules, rather than trying to improve this I think it would make more sense to put effort into making sure the node-api flow detects different setups better. Perhaps in v8 it should be switched to assume it is node-api unless it detects otherwise. I am not aware of any good reason to make non node-api modules anymore, other than existing modules which haven't been able to justify the work to port.

[audetto]

Thanks. That made a big difference.