Skip to content
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

Closed
wolfv opened this issue Aug 2, 2019 · 9 comments
Closed

Extension Problems with ws #6934

wolfv opened this issue Aug 2, 2019 · 9 comments
Labels
status:resolved-locked tag:Build System
Milestone

Comments

@wolfv
Copy link
Member

@wolfv wolfv commented Aug 2, 2019

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 case RosLib.js get's compiled to module.export = ws; where ws is undefined. This breaks my application and so far the only workaround I have found is to patch the library by removing var WebSocket = require('ws'); (since WebSocket is implemented in the browser this is no big deal).

@martinRenou has worked around this by doing window.ws = WebSocket in ipywebrtc:

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 remove ws.

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).

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Aug 2, 2019

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)

if (typeof window === 'undefined') {
// Mangle the require statements so it does not get picked up in the
// browser assets.
/* tslint:disable */
let fetchMod = require('node-fetch');
FETCH = global.fetch || fetchMod;
REQUEST = global.Request || fetchMod.Request;
HEADERS = global.Headers || fetchMod.Headers;
WEBSOCKET = global.WebSocket || require('ws');
/* tslint:enable */
} else {
FETCH = fetch;
REQUEST = Request;
HEADERS = Headers;
WEBSOCKET = WebSocket;
}

@wolfv
Copy link
Member Author

@wolfv wolfv commented Aug 2, 2019

yeah, totally, that would be great. However, I don't control the code that does require('ws') which makes this a bit more tedious otherwise I would use this fix right away!

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Aug 2, 2019

Right - I meant that as a pattern libraries could use. I understand the dependency problem here.

@wolfv
Copy link
Member Author

@wolfv wolfv commented Aug 3, 2019

I have checked jupyterlab for all occurences of this pattern and it seems that only the services package sets "browser": { "ws": false ...}

However, another thirdparty library (engine.io-client) also sets this. So I am wondering – if I revert the PR doing this, will it work or will the setting of engine.io-client override this?
Also, what's the best way to test this?

I would really like if this can go into the next release because I wasted way too much time on ws being undefined.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Aug 5, 2019

The underlying issue that this change fixed is #5856. Can we can still solve #5856 even if we remove this field?

@bollwyvl
Copy link
Contributor

@bollwyvl bollwyvl commented Aug 6, 2019

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 🤷‍♂️

@wolfv
Copy link
Member Author

@wolfv wolfv commented Aug 6, 2019

@wolfv
Copy link
Member Author

@wolfv wolfv commented Aug 6, 2019

e.g.

  "browser": {
    "node-fetch": false,
    "ws": "./myWsShim.js"
  },

where myWsShim.js contains

module.exports = WebSocket;

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 25, 2020

Fixed by #7780?

@jasongrout jasongrout added this to the 2.0 milestone Feb 25, 2020
@lock lock bot added the status:resolved-locked label Mar 27, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:resolved-locked tag:Build System
Projects
None yet
Development

No branches or pull requests

4 participants