Activating extension xxx failed: Module version mismatch. Expected 49, got 48..

[DonJayamanne]

• VSCode Version: Insider
• OS Version: OS X Elcapitan
• nodejs Version: 6.7.0
• npm Version: 3.10.8

Steps to Reproduce:

1. Clone git repo pythonVSCode
2. Start debugging

I also tried this with nodejs 4.6.0 and npm 3.10.7, and still get a similar message (Activating extension donjayamanne.python failed: Module version mismatch. Expected 49, got 46..).

Error displayed:

Activating extension `donjayamanne.python` failed: Module version mismatch. Expected 49, got 48..
Activating extension `donjayamanne.python` failed:  Module version mismatch. Expected 49, got 48.
Here is the error stack:  Error: Module version mismatch. Expected 49, got 48.
    at Error (native)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:168:20)
    at Object.Module._extensions..node (module.js:583:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:168:20)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Function.I.N.n._load (/Users/donjayamanne/Downloads/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:13:19970)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)

[Tyriar]

cc @DonJayamanne

[DonJayamanne]

@Tyriar
Managed to narrow down the issue to the jmp package.

1. npm install --save jmp
2. Add the following line to your extension.ts file const jmp = require('jmp');
3. Launch the extension from vs code (debugger)

[bpasero]

@DonJayamanne assigning to you for now as I can not npm install this project without errors such as:

(node:8164) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
npm ERR! registry error parsing json
npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated jade@0.26.3: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN prefer global marked@0.3.5 should be installed with -g

> fsevents@1.0.14 install /Users/bpasero/Development/Microsoft/pythonVSCode/node_modules/fsevents
> node-pre-gyp install --fallback-to-build

[fsevents] Success: "/Users/bpasero/Development/Microsoft/pythonVSCode/node_modules/fsevents/lib/binding/Release/node-v48-darwin-x64/fse.node" is installed via remote

> zmq@2.15.3 install /Users/bpasero/Development/Microsoft/pythonVSCode/node_modules/zmq
> node-gyp rebuild

/bin/sh: pkg-config: command not found
gyp: Call to 'pkg-config libzmq --libs' returned exit status 127 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:305:16)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Darwin 15.6.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/bpasero/Development/Microsoft/pythonVSCode/node_modules/zmq
gyp ERR! node -v v6.5.0
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok 
python@0.4.0 /Users/bpasero/Development/Microsoft/pythonVSCode

It seems you are using native modules as dependencies for the extension. That is very very dangerous because each time we update Electron, your extension will fail to execute. If possible, please replace native modules with a JS implementation. If that is not possible you will have to publish an update each time we bump Electron version and mark it compatible only with the version we updated to. It is expected that each time we update Electron the node.js version will change, so you will be broken roughly every other release.

Now the error message is weird because it talks about version 49 and 48 (which I believe is node.js 4.x). We are shipping with node.js 6.5.0 which has a module version of 51. To be on the safe side for compilation you can use our npm.sh script that we use for VS Code (https://github.com/Microsoft/vscode/blob/master/scripts/npm.sh#L1) and configure it to electron 1.3.7. You can also use node.js 6.5.0 or later to install the dependencies.

[DonJayamanne]

@bpasero , thanks will try that out

[DonJayamanne]

@bpasero
Thanks for the information, that worked.

your extension will fail to execute

I'll refactor the code such that the dependency is placed inside of a try catch using traditional require('jmp'). This way, it won't bring down the entire extension even if that particular module doesn't load.

If possible, please replace native modules with a JS implementation

Will look into this.

We are shipping with node.js 6.5.0 which has a module version of 51

I did install node.js 6.5.0 and then installing the dependencies, but that didn't work. I think it may have been the module version.

@bpasero , two final queries:

• What is this module that you are referring to here We are shipping with node.js 6.5.0 which has a module version of 51?
• When when I add the following code into my extension console.log(process.versions), and then debug it, I get the value 49. Is this modules version something different?

Object
http_parser:"2.7.0"
node:"6.5.0"
v8:"5.2.361.43"
uv:"1.9.1"
zlib:"1.2.8"
ares:"1.10.1-DEV"
modules:"49"
openssl:"1.0.2h"

[bpasero]

@DonJayamanne looks like you are right, it is 49, at least in Electron. The source of proof always is here: electron/node@3ce8afa

What number there is does not play an important role. The key take away is that every Electron update we do will require all native modules to be recompiled. Thus it is not practical to have such a dependency in extensions at all 👍

[DonJayamanne]

@bpasero , thanks

Thus it is not practical to have such a dependency in extensions at all

Agreed, but will need to go with the temporary approach for now.

[mike-lischke]

Supporting native C++ modules in Node.JS is one of the greatest feature of it and discouraging extension developers from using native modules is a slap in their face. It would be better if the ABI would stabilize finally, so that no module version bump is necessary.

I'm affected by this issue as well, which is caused by the version bump in the electron/node fork. There is no official Node.JS version yet that uses 49, so it's impossible to recompile native modules for the current VS Code version, which is a PITA and really should not happen at all (for a tool in production use). I wonder how all the other extensions with native modules cope with such a situation, where any VS Code will likely break them (and there are quite a few).

Please, don't just discourage extension developers, but find a way to avoid frequent node module version changes (or be more tolerant which node module version is accepted, if possible).

Thank you.

[bpasero]

@mike-lischke take it easy, an aggressive tone in comments is not helpful and might discourage people from helping you.

Of course you can compile native modules against VS Code. we ship with native modules in VS Code ourselves and make great use of C/C++ modules.

The key is in the configuration of the npm install script. If you look at our https://github.com/Microsoft/vscode/blob/master/scripts/npm.sh script you can see that we set some NPM headers so that the right configuration is there for Electron. Together with the right Electron version (which we get from the package.json) you should be able to compile the extension without any issues against Electron 1.3.7.

We cannot keep any ABI compatibility, how would we? Electron is moving forward and so is node.js. Even if we decide to ship our own version of node.js, we would have to include all node.js versions we ever supported which is a pain to maintain and find issues.

The best way for us is to move forward with Electron and node.js and make it clear for extension writers that native modules need to be updated when we update Electron. You can still do it, its just a bit more work for you to keep up to date.

[mike-lischke]

I'm sorry if my comment came across with a bad attitude. It's the result of reading that you apparently no longer want to encourage extension developer to use native modules just because it can be a pain to keep them up to date (you even commented it would be very dangerous).

Actually, this is rather an Electron problem (and I filed a bug report there. However, in the meantime I learned that extension developers are supposed to compile against Electron's node.js variant. So far it appeared to me as if that was optional and so far it also worked for me to use the system node.js version for compiling my extension (well, except on Windows).

What would help from your side is that you don't update Electron too often, but instead do this only in larger time frames (say once in 6 months) to avoid breaking extensions too often. That was mostly what I'd like to wish as a compromise.

[DonJayamanne]

hi @mike-lischke , apologies for not getting back earlier.
The use of native modules introduces a few issues specially for extensions in VS Code. These are the issues identified:

• Every time node.js in VS Code (Electron) changes, the extension breaks
• The solution would be to then update the extension to use the latest version of node.js found in the latest version of VS Code
• Once the extension is updated, the extension can only be used with that particular version of VS Code (i.e. if you update VS Code, you must update the extension and vice versa)
• Yes we could have compromises or find work arounds like using zmq-prebuilt. However, at the end of the day these are work arounds.

I believe when it comes to extensions for VS Code it is best to try and avoid the use of native modules (where possible) for ease of maintenance and end user experience.

[wmertens]

It goes even further than that - if you use e.g. a linter and then through configuration that includes a binary module, that breaks too. (eg. xo-linter and import loader webpack resolver)

I wish there was a way to fix this but I can't really think of anything :(