Fixes for `ws` isomorphism

[tegefaulkes]

Specification

While we have some isomorphism working to some degree, we're still running into issues with the deployed version of PKE. Otherwise it currently works when hosting locally.

The main issue is that some node modules are being included in the bundled client code. Even if these are not used the very existence of these imports in the client on the browser results in CORS errors trying to import them. We need to remove any chance of these imports when using the WebsocketClient entirely.

To fix this we just need to ensure that no node imports are done within any imports used by the client side code. The client side needs to be fully isomorphic however the server will not be supported within browsers.

Just skimming through the code I can see that utils.ts and WebsocketStream.ts has imports to node modules. These are also common to server and client code. We'll need to look into isomorphic wrappers for these node modules.

Additional context

• Previous work: feature: isomorphic WebSocket support #32
• Previous work: Isomorphic js-ws #6

Tasks

1. Review Isomorphic changes from Pull feature: isomorphic WebSocket support #32
2. Look into Isomorphic wrappers for node modules
3. Look into isolating node imports from client related code.
4. Remove polyfills from Polykey-Enterprise when this has been resolved.

[linear]

ENG-468 Fixes for ws isomorphism

[CMCDragonkai]

In many cases, I prefer to just write out the utility functions they need if they are simple enough. What are the functions/constants that are required?

[CMCDragonkai]

This is affecting https://github.com/MatrixAI/Polykey-Enterprise/issues/112.

Because js-ws is being used in the frontend and thus bundled. It's relying on remix vite configuration to alias certain imports, which atm is just passing through whatever is the implementation in the browser. This isn't safe, cause you're relying on environmental context, which is very browser specific (and version specific).

Most things here should be replaceable with inlined implementations, some basic functionalities can use the browserify versions...

This is a common problem with using npm dependencies that were developed for the node runtime. Generally the idea is that if the node runtime does provide it, you want to continue using it, rather than bringing your own implementation since it keeps the library minimal.

However when you are expecting to use it in the browser too, then in our case, where we can inline things, we should, where we can't, we can substitute the dependency with something conditionally. That usually is why in our package.json has browser field: https://stackoverflow.com/a/74240581.

That is a hint to the bundler to use that version instead, in particular see this: https://github.com/defunctzombie/package-browser-field-spec?tab=readme-ov-file#replace-specific-files---advanced.

Note that doing so should require the CI to simulate a browser environment too for testing.

[CMCDragonkai]

Note that we should not require https://github.com/cyco130/vite-plugin-cjs-interop if this package is changed to ESM.

[CMCDragonkai]

Sorry I mean https://github.com/matrixai/js-rpc is turned into ESM.

It should be possible now none of its dependencies are not ESM.

[CMCDragonkai]

I raised an issue MatrixAI/js-rpc#78 in, it is not really related to this problem.

[CMCDragonkai]

This commit on PKE https://github.com/MatrixAI/Polykey-Enterprise/commit/27ad45b92ae98c21c399749dfd37fca2a936e751#diff-6a3b01ba97829c9566ef2d8dc466ffcffb4bdac08706d3d6319e42e0aa6890ddR39 needs to be reverted or the contents removed for this fix.

[CMCDragonkai]

We need a corresponding issue here for js-rpc since it is pushing a bunch of hacks onto PKE as per https://github.com/MatrixAI/Polykey-Enterprise/pull/113