-
Notifications
You must be signed in to change notification settings - Fork 571
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
Not building uws correctly? #536
Comments
I'm getting the same in stdout, but the latter error is a question of setting the right location for your openssl headers. Something like however, for me that doesn't remove the first error and it's doing my head in |
this was a nightmare of a bug. my solution: eliminate socketio. i was looking for an excuse to use webrtc as the interwindow ipc mechanism in electron anyway... |
Set environment variable |
Fixes socketio#536 Fixes socketio#516 Fixes socketio#474
Related: - socketio/socket.io#2956 - socketio/socket.io#3100 Fixes #536 Fixes #516 Fixes #474
|
What's the best way to resolve this? |
Wow, that's a lot of downvotes. Yeah, I guess it all falls on me to somehow fix up completely separate environments that I didn't even target.
Electron is not providing OpenSSL headers, go shame Electron for this - I'm no magician and I cannot just make third-parties obey by Node.js rules. They are not even the same platform! This would be the same as Consider this thought experiment: What if I took, say, Express.js and shoved that JavaScript code into a third-party JavaScript environment that lacked 90% of all prorgamming interfaces that are in Node.js. Would you blame Express.js for this? Because it obviously wouldn't work. What if I took Socket.IO and tried to run it in a Python environment? Ruby environment? You starting to get my point? I can't fix things I have no control over and I never said it would work in Electron, they are not the same platform just because a portion of some JavaScript happens to work in both. C++ is not scripting, you can't just take a Box and shove it through a Round hole and expect it to just magically work. In any case, just use ws instead because with Socket.IO you don't see any difference since the bottleneck is not in ws nor uws, it is in Socket.IO itself. |
In case anyone stumbles across this and is confused about how to switch to ws from uws, I found that you can just change this on the options, for instance: var io = require('socket.io')(80, { wsEngine: 'ws' }); If there's a better way, please correct me. |
if you use socket io in node install this as well : npm i --save uws |
@Donutttt @mtrabelsi So by default, The performance of the ws package can be improved with two native libs (which are not included by default):
To use uws, you have to install it and select it as
Hope that clears things up! |
I solved this in WebStorm by entering |
I'm not sure if this is a bug per-se because i don't know who is building uws, but the problem is manifesting itself there and the only module requiring it is this one so here i am.
You want to:
Current behaviour
error on build in uws
Expected behaviour
not to error on build
Setup
Other information (e.g. stacktraces, related issues, suggestions how to fix)
in stdout
in build log
The text was updated successfully, but these errors were encountered: