deasync not working under Electron 1.3.2

[eddieqiii]

On attempting to use deasync w/ electron-prebuilt@1.3.2, node v4.4.7 on Linux Mint 18, it throws an error:

(bindings.js:91) Uncaught Error: Could not locate the bindings file. Tried:
 → /(path to project)/node_modules/deasync/build/deasync.node
 → /(path to project)/node_modules/deasync/build/Debug/deasync.node
 → /(path to project)/node_modules/deasync/build/Release/deasync.node
 → /(path to project)/node_modules/deasync/out/Debug/deasync.node
 → /(path to project)/node_modules/deasync/Debug/deasync.node
 → /(path to project)/node_modules/deasync/out/Release/deasync.node
 → /(path to project)/node_modules/deasync/Release/deasync.node
 → /(path to project)/node_modules/deasync/build/default/deasync.node
 → /(path to project)/node_modules/deasync/compiled/6.3.0/linux/x64/deasync.node
    at bindings (/(path to project)/node_modules/deasync/node_modules/bindings/bindings.js:88:9)
    at /(path to project)/node_modules/deasync/index.js:34:32
    at Object.<anonymous> (/(path to project)/node_modules/deasync/index.js:76:2)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    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)bindings @ bindings.js:88(anonymous function) @ index.js:34(anonymous function) @ index.js:76Module._compile @ module.js:541Module._extensions..js @ module.js:550Module.load @ module.js:458tryModuleLoad @ module.js:417Module._load @ module.js:409Module.require @ module.js:468require @ internal/module.js:20(anonymous function) @ VM116:1

However, deasync works fine when using it in a normal nodejs (still v4.4.7) context.

(Similar to #47 but not on Windows - not sure if same issue so I opened a new issue)

[eddieqiii]

Update: deasync works fine under electron-prebuilt@0.37.8 (the release before 1.x.x) but does not work on 1.3.2.

[timtutt]

@BobMakingPie - did you ever find a solution/workaround to this. I'm running into the same issue.

[abruneau]

I'm having the same issue with electron 1.4.0

[Xosmond]

Same issue here on electron 1.4.2

[timtutt]

So the issue is actually with Electron - any version greater than 1.30. As of that version they upgraded to Chromium to 52 which does not match the NodeJs V8 version which as of 6.7.0 is 5.1.281.83.

Per the following lines when deasync loads it looks for the executable in the directory that matches the v8 version (in the case of node 6.7.0 v5.1) although in Electron this value is v5.2.:
var nodeV = 'node-' + /[0-9]+\.[0-9]+/.exec(process.versions.node)[0];
var nodeVM = 'node-' + /[0-9]+/.exec(process.versions.node)[0];
var modPath = path.join(__dirname, 'bin', process.platform + '-' + process.arch + '-' + nodeV, 'deasync');
(https://github.com/abbr/deasync/blob/master/index.js#L20)

Trying to manually change the folder causes a mismatch issue in the binary generated... Unless anyone has any ideas of how to compile with the node version used by Electron vice the nodejs version installed on the machine, I'm a bit stalled at the moment....

[veger]

I found a way to 'fix' this issue (locally), by manually rebuilding deasync.node

Electron (Arch Linux package, version 1.4.5-1) uses abi version 51. deasync binaries for node-6 are compiled for 50 and for node-7 are compiled for 52...

So no pre-build binary for abi version 51 is available.

By manually compiling deasync abi version 51 can be obtained:

1. Open terminal to root of installed module (use npm install deasync)

2. Remove bin folder from deasync (optional step, but it makes clear that the/which binary is recompiled)

3. Compile with npm install --runtime=electron --target=1.4.5 --disturl=https://atom.io/download/atom-shell --abi=51

   target is my electron version
   abi is my require electron abi version
   Thread where I got this information from

Using the compiled binary I am able to run atom with atom-standard-formatter package (which was the reason for me to recompile deasync binaries)

I am no expert, so I cannot tell if this works for any other installation, but these where the steps I took to 'fix' my problem.

Hopefully, someone more experience is able to properly fix this!

[stanleyxu2005]

Yes, rebuild from source will fix the issue. This is common issue with gyp-rebuild projects. You can refer zeromq.js to see how it is compiled against your local node header files.

(I think author or admin can close this issue)

[obermillerk]

This is really frustrating. I'm trying to make a module that I will use in an electron app and I can't manually rebuild deasync every time because I want to be able to just require my module as a dependency without the user having to do more work.

EDIT: UNRELIABLE, SEE BELOW
I found a workaround where instead of actually making deasync a dependency, I install it in the postinstall script of my module and then use npm explore to find deasync's install and rebuild using node-gyp. "postinstall": "npm install -E deasync@0.1.10 && npm explore deasync -- node-gyp rebuild" I had to do it this way since there doesn't seem to be a guarantee that deasync will be installed before my library so I can't just make it a dependency and then do only the rebuild in the postinstall.

It would be great to take advantage of the prebuilt binaries to save that time, but they're not in the right place. Is there any detriment to having the corresponding folder be copied as a build folder in the root on install (even a sym-link, perhaps preferably a sym-link)? This would make it compatible with electron and still take advantage of prebuilt-binaries.

EDIT: I just tested both the copy and sym-link methods and it didn't work so I redact that suggestion but a fix for this would still be greatly appreciated.

[jonbarrow]

@obermillerk Just tried your solution, didn't work for me. This solved the initial error, but now (Using Electron 1.7.8) I get this error:

Error: A dynamic link library (DLL) initialization routine failed.
\\?\C:\Users\REMOVED\Documents\Programming\Electron\sql\node_modules\deasync\build\Release\deasync.node
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:173:20)
    at Object.Module._extensions..node (module.js:598:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:173:20)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at bindings (C:\Users\REMOVED\Documents\Programming\Electron\sql\node_modules\bindings\bindings.js:76:44)
    at C:\Users\REMOVED\Documents\Programming\Electron\sql\node_modules\deasync\index.js:34:32

[obermillerk]

@RedDuckss I don't quite recall, but I may have run into that as well, otherwise it might be something else. What I ended up doing instead was modifying the deasync library so that it doesn't use the prebuilts and instead rebuilds for the local node version on install. Then I could pack it in a tar file, upload that somewhere (such as part of a github repo) and install from that. It would still have to be rebuilt again for electron, but I would think that would be part of your process already.

Here is a zip file containing a tarball of my modified deasync library, with build script and prebuilt binaries removed since they are no longer needed.
deasync-0.1.10-custom.zip

EDIT:
You can install from the tarball by giving npm a relative path such as npm i ../custom_modules/deasync-0.1.10-custom.tgz
If you're using this in a module you want to publish to npm, you can install from the tarball and then add deasync as a bundledDependency by adding "bundledDependencies": ["deasync"] to your package.json, and when you do npm publish it packs the locally installed version of deasync with your module and it will install it as a sub-module when your package is installed from npm.

EDIT 2:
Also note that if you want to install from the tarball when your module is pulled from npm rather than making it a bundledDependency, you cannot rely on the tarball file being present as a local file, you should instead point to it being hosted remotely somewhere. This last one could be risky if your host goes down, so I'd recommend the bundled approach as they will get everything from npm (or nothing at all).