Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opposite of --ensure, and is --ensure still useful? #1216

Closed
gibfahn opened this issue May 31, 2017 · 3 comments
Closed

Opposite of --ensure, and is --ensure still useful? #1216

gibfahn opened this issue May 31, 2017 · 3 comments

Comments

@gibfahn
Copy link
Member

gibfahn commented May 31, 2017

I was looking for a way to force node-gyp to re-download the headers even if the directory already exists in $npm_config_devdir/$node_version, and I found --ensure, which seems to do the opposite.

As I understand it, node-gyp doesn't download the headers unless the directory is missing, so --ensure is the default behaviour. Am I missing something? Is there a --always-redownload option (and should there be)?

Obviously as a workaround you can do this before the node-gyp rebuild or npm install:

node "$(npm config get prefix)"/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js remove $(node -p process.versions.node) 
@gibfahn gibfahn changed the title Opposite of --ensure still useful? Opposite of --ensure, and is --ensure still useful? May 31, 2017
@gibfahn
Copy link
Member Author

gibfahn commented May 31, 2017

Thinking about this further, if the --tarball option is passed, I think it makes sense to delete the header directory and recreate it.

Thoughts?

@bnoordhuis
Copy link
Member

As I understand it, node-gyp doesn't download the headers unless the directory is missing, so --ensure is the default behaviour. Am I missing something?

That's correct. It's unconditionally set in lib/configure.js.

Is there a --always-redownload option (and should there be)?

I don't think so. What good would it do?

Thinking about this further, if the --tarball option is passed, I think it makes sense to delete the header directory and recreate it.

I suppose. It could piggyback on the remove command.

@gibfahn
Copy link
Member Author

gibfahn commented Jun 2, 2017

I don't think so. What good would it do?

I ran into this because we were testing v8.0.0-pre, and node-gyp didn't re-download the headers, which meant that we got lots of this error when the NODE_MODULE_VERSION was updated:

module.js:598
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: The module '/space/jenkins-local/workspace/ibm-node8-appmetrics/ARCH/x64/CC/gcc48/OS/linux/label/build/node-v8.0.0-linux-x64/lib/node_modules/appmetrics/appmetrics.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 55. This version of Node.js requires
NODE_MODULE_VERSION 57. Please try re-compiling or re-installing

When running in CI I always want to redownload the headers.

If the "--tarball always reinstalls the headers" option is acceptable I'm happy with that.

gibfahn added a commit to gibfahn/node-gyp that referenced this issue Jun 2, 2017
If you're providing a path to a header tarball to install, you probably
want it to always be re-installed.

Fixes: nodejs#1216
gibfahn added a commit that referenced this issue Jun 7, 2017
If you're providing a path to a header tarball to install, you probably
want it to always be re-installed.

PR-URL: #1220
Fixes: #1216
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants