Socket.io crashes loading in Electron on MacOS

[nicolasnoble]

You want to:

• report a bug
• request a feature

Current behaviour

Loading socket.io fails under MacOS with the Electron runtime:

dyld: lazy symbol binding failed: Symbol not found: _SSL_library_init
  Referenced from: /Users/nnoble/test/node_modules/uws/uws_darwin_57.node
  Expected in: flat namespace

dyld: Symbol not found: _SSL_library_init
  Referenced from: /Users/nnoble/test/node_modules/uws/uws_darwin_57.node
  Expected in: flat namespace

Steps to reproduce (if the current behaviour is a bug)

On MacOS:

$ git clone https://github.com/nicolasnoble/socketio-electron-testcase.git
$ cd socketio-electron-testcase
$ npm install
$ npm start

Expected behaviour

Loading the module properly.

Setup

• OS: MacOS 10.13.3
• browser: not applicable
• socket.io version: 2.0.4
• Electron version: 1.8.4

Other information (e.g. stacktraces, related issues, suggestions how to fix)

This issue is highly linked to #2984, in a very bad way. It seems the uws extension code is trying to load the nodejs runtime under Electron, which is utterly wrong and helplessly broken, especially since the uws extension seems to be no longer maintained. The two runtimes are different when it comes to symbols and behavior, and trying to load a node extension into the Electron runtime simply will never work properly in all platforms. This may kinda works on some, but evidently, not on MacOS.

The uws extension seems like a bad dependency to have for being able to run on all runtimes and platforms, and potentially relying on nodejs/node#19308 to pass might be the right thing to do here.

[ghost]

and trying to load a node extension into the Electron runtime simply will never work properly

uws is not an Electron module and never said it was. It is a Node.js module and will also fail if you try and run it as a PlayStation 4 game. It also does not work on AmigaOS.

Socket.IO should put in a switch that checks if it is running as an Electron module or not, and switch to ws as needed.

It seems the uws extension code is trying to load the nodejs runtime under Electron, which is utterly wrong and helplessly broken

Um, no. It seems you are trying to use a Node.js module as if it was something completely different and then blame the failure on someone else.

[nicolasnoble]

I'm sorry, I don't understand your point at all. If I could still enter a bug on uws, I would, but since its whole repository, source code, and issue tracker disappeared, I can't do that.

The rootcause is that when uws is trying to load, it blindly tries to load a pre-compiled module, with no other checks such as Electron. Now, I am not the one loading uws. Socket.io is doing it for me, and I don't seem to have any sort of control myself about how socket.io is doing this. Now, from a more reasonable bug report, since you seems to be the author of uws, if you are still maintaining the product despite the lack of a visible repository holding the source, I would believe the right thing to do would be to avoid doing a require of a pre-compiled module unsuitable for the runtime you're running against, in order to be a nicer package and avoiding to push that kind of runtime responsibility up to your dependents. With the current behavior of uws, it means any dependent such as socket.io would need to know about the specifics of how to load it, whereas that logic could easily be factorized into it.

[ghost]

If I make a hammer and people try and use it as a saw, it is not my problem.

From the start I have targeted NPM + Node.js and nothing else. When people try and use it in the browser, in Electron, in NEXE, in WebPack, on FreeBSD, on OpenBSD, inside an oven, on an iWatch or under water it's not my task to check for that case. There are literally hundreds of different set-ups and combinations of different environments that people combine in any way they see fit.

I only target Node.js and it works for Node.js, everything else is just invalid usage. There is no "blind" loading of pre-compiled binaries - they are ordered by official Node.js ABIs and follows official Node.js docs for native addons.

[nicolasnoble]

Right, and that attitude right there tells me that uws is the wrong fit for socket.io, and that if socket.io is willing to keep on forcing people to use uws, then socket.io is also in the wrong.

Thanks, I will seek to use another project.

[ghost]

No problem.