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
Extension Problems with ws
#6934
Comments
It does sound like that PR might be the relevant one. On the relevant issue, @saulshanabrook points out a way we work with this in services: #5856 (comment) jupyterlab/packages/services/src/serverconnection.ts Lines 16 to 31 in 52a3305
|
yeah, totally, that would be great. However, I don't control the code that does |
Right - I meant that as a pattern libraries could use. I understand the dependency problem here. |
I have checked jupyterlab for all occurences of this pattern and it seems that only the services package sets However, another thirdparty library ( I would really like if this can go into the next release because I wasted way too much time on |
Depending on how dirty you mind getting, this has worked for me in the past ( // eew
(window as any).ws = WebSocket;
// this kicks off the dep chain
const {makeWidget} = await import(/* webpackChunkName: "jupyterlab-outsource-yjs" */ './widget'); Not proud of it, though 🤷♂️ |
I think instead of false it's also possible to put the path of a shim file.
Maybe that shim file could contain the piece of code mentioned?
…On Tue 6 Aug 2019 at 05:14, Nicholas Bollweg ***@***.***> wrote:
Depending on how dirty you mind getting, this has worked for me in the
past (./widget.ts -> yjs -> socket.io -> engine.io):
// eew
(window as any).ws = WebSocket;
// this kicks off the dep chain
const {makeWidget} = await import(/* webpackChunkName: "jupyterlab-outsource-yjs" */ './widget');
Not proud of it, though 🤷♂
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6934?email_source=notifications&email_token=AAGYCPXEYTEETC5DND65KPLQDDUALA5CNFSM4II6UIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3TWEII#issuecomment-518480417>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGYCPRYX5UTNWWXWYEWPPDQDDUALANCNFSM4II6UIUA>
.
|
e.g.
where
|
Fixed by #7780? |
Lately I have created JLab widgets that use a thirdparty library that relies on
ws
for WebSockets.But when I install this extension using JupyterLab, the
require('ws')
of this thirdparty library (in my caseRosLib.js
get's compiled tomodule.export = ws;
wherews
is undefined. This breaks my application and so far the only workaround I have found is to patch the library by removingvar WebSocket = require('ws');
(sinceWebSocket
is implemented in the browser this is no big deal).@martinRenou has worked around this by doing
window.ws = WebSocket
inipywebrtc
:https://github.com/maartenbreddels/ipywebrtc/blob/839d98a5a7c134f577875993368279dfce8365a0/js/src/webrtc.js#L6-L8
which for some reason does not work for me (include order basically).
I think
ipyvolume
(cc @maartenbreddels) was running into the same issue but there it was no issue to just removews
.I suspect that this PR might be the cause, as this behavior only manifested itself after the 1.0 release (afaik).
#5945
If this could be fixed somehow I would be very happy (even though I agree of course that this library is not necessary in the browser, and maybe the thirdparty libs should just do the right thing).
The text was updated successfully, but these errors were encountered: