"Error: Could not locate the bindings file."

[gnestor]

I ran into this issue and solved by uninstalling and reinstalling ijavascript globally. It probably was related to the initial installation being installed with Node < 6 and an update being installed with Node 6.

/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:91
  throw err
  ^

Error: Could not locate the bindings file. Tried:
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/out/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/Debug/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/out/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/Release/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/build/default/zmq.node
 → /usr/local/lib/node_modules/ijavascript/node_modules/zmq/compiled/5.12.0/darwin/x64/zmq.node
    at bindings (/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:88:9)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/lib/index.js:6:30)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/index.js:2:18)
    at Module._compile (module.js:413:34)

[rgbkrk]

Yeah I run into this with every upgrade too. We need to find some way to link to one of these issues about it/documentation around it.

[n-riesco]

@rgbkrk Perhaps we should open an issue at the npm repository. Ideally, when node changes, we'd like npm to recompile all the native modules.

[gnestor]

@n-riesco What if ijavascript added an npm postinstall script that runs npm rebuild?

[n-riesco]

@rgbkrk @gnestor Could you post some instructions to reproduce this issue? And perhaps also the output of npm --versions?

[n-riesco]

Would you be able to check whether adding zmq to the dependencies in package.json works around this issue?

[gnestor]

I use the n package to switch between versions of Node. To reproduce:

1. Install ijavascript using Node ^5
2. Switch to Node ^6
3. Run jupyter notebook using jupyter notebook or ijs
4. Create a new notebook with "Javascript (Node.js)" kernel
5. The kernel dies and the output in the terminal is:

[I 08:37:04.501 NotebookApp] Kernel started: 655e00a7-0e94-499b-8b9e-79d28f380309
/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:83
        throw e
        ^

Error: Module version mismatch. Expected 48, got 47.
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at bindings (/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:76:44)
    at Object.<anonymous> (/usr/local/lib/node_modules/ijavascript/node_modules/zmq/lib/index.js:6:30)
    at Module._compile (module.js:541:32)
[I 08:37:07.471 NotebookApp] KernelRestarter: restarting kernel (1/5)
/usr/local/lib/node_modules/ijavascript/node_modules/bindings/bindings.js:83
        throw e
        ^

To fix, either:

• Switch back to Node ^5 and retry
• Run npm rebuild inside of the ijavascript directory and retry

Again, adding an npm postinstall script that runs npm rebuild will fix the issue I experienced which was produced by running npm install -g ijavascript in a different version of Node (because npm install doesn't automatically rebuild native modules). However, if a user switches versions of Node and doesn't run npm install -g ijavascript, then they will encounter this error and there is really nothing we can do about it (and there's really nothing npm can do about it either). To address this, perhaps something along these lines could be added to the README:

Known issues

• "Error: Could not locate the bindings file": This is caused by installing ijavascript using one version of Node (e.g. Node 5) and running Jupyter Notebook using another version (Node 6). npm needs to rebuild ijavascript's native modules and bindings for Node 6 in order to use it with Node 6. To resolve this error, switch to the target Node version (e.g. Node 6) and reinstall ijavascript (npm install -g ijavascript).

Lastly, zmq is the culprit here because it's zmq's native modules that need to be rebuilt, so removing the dependency on zmq's native modules would resolve this issue and I believe this is something that @rgbkrk has been working on...

[n-riesco]

@gnestor The error message you get now is different. The original error message in this issue was Error: Could not locate the bindings file..

@rgbkrk What error message do you get in your case?

An Error: Module version mismatch. Expected 48, got 47. is expected whenever process.versions.modules changes (e.g. when Node is upgraded from 5 to 6). In this case, users should be advised to run npm rebuild (or apm rebuild if an electron app?), rather than running npm install.

[gnestor]

@n-riesco You're right! I had an older version of ijavascript installed (probably 1 year old) and I ran npm install -g ijavascript to update it (which didn't rebuild). I encountered this error, uninstalled, and reinstalled (which did rebuild) and the error went away.

One issue with instructing users to run npm rebuild is that you can't run it globally (e.g. npm rebuild -g ijavascript), so the user would need to run it within the ijavascript directory, which if installed globally would be somewhere like /usr/local/lib/node_modules/ijavascript.

[rgbkrk]

This makes me wonder if having an ijs --upgrade option would allow us to do it intelligently. That or we rebuild on start up. Both of these may be silly ideas though.

I'm an nvm user, so the messages are quite similar to n. Sometimes the entire directory for an old version gets nuked by me, and it's the version that was mapped in the kernel spec. I'm used to dealing with native module and upgrades so I just install all over again (unlike a global node install).

[n-riesco]

I've opened an issue in the jmp repository.

[n-riesco]

Moved back from n-riesco/jmp#15

[n-riesco]

After the experience gained with n-riesco/jp-babel@2c7227c I'm convinced this rebuild issue shouldn't be handled by a package itself, because the package would have to know about the environment were it has been installed (is it plain npm? is it electron? ...).

For this reason, I'm going to close this issue.