Cannot access "child_process.spawn" in client code, with Vite 3.0 and Socket 2.5.0
Describe the bug
Issue with xmlhttprequest-ssl and vite 3.0 when doing vite or vite build & vite preview
To Reproduce
Socket.IO client version: 2.5.0
Vite version: 3.0
React version: 18.2.0
Client
We set the socket connection in abstract way with react-query. The connection part looks pretty the same as your example with some tweaks, but the issue is probably deeper inside the package xmlhttprequest-ssl
import { io } from "socket.io-client";
const _socket = io(`${import.meta.env.VITE_WSS_URL}`, {
query: {
pathname: window.location.pathname,
sw: window.innerWidth,
sh: window.innerHeight,
b: browser?.name,
token: response.token,
p: 'example',
},
transports: ['websocket'],
});
Expected behavior The socket connection should be successfully established, and we should receive events
Platform:
- Chromium 102
Additional context As an error we receive
browser-external:child_process:9 Uncaught Error: Module "child_process" has been externalized for browser compatibility. Cannot access "child_process.spawn" in client code.
which leads us to
It also might be connected with new Vite's websocket connection strategy https://vitejs.dev/blog/announcing-vite3.html#dev-improvements
@luksari Try updating to the latest version of socket.io i had the same problem
@Sitronik There is no possibility to upgrade it as I handle external websocket events emitted by 2.x version of engine
same problem here
Any solution for this? I am also stuck on version 2.x and need this to work.
Any solution for this? I am also stuck on version 2.x and need this to work. @martinszeltins I fixed this yesterday by this command
npm install socket.io-client@latest
this will bring you to the current working version which is "socket.io-client": "^4.5.1",
Note that socket.io and socket.io-client is a different stuff
Some of us are still stuck using socket.io-client 2.x specifically. For example Feathersjs v4 only works with 2.x. While it's solved in the upcoming v5, most devs are using the stable release.
So we cannot update to @latest.
I have the same issue, being stuck at 2.x
Same here....
Same with ...
try to use @esbuild-plugins/node-modules-polyfill
vite.config.ts as follow
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { NodeModulesPolyfillPlugin } from "@esbuild-plugins/node-modules-polyfill";
export default defineConfig({
plugins: [react()],
optimizeDeps: {
esbuildOptions: {
plugins: [NodeModulesPolyfillPlugin()],
},
},
});
It's happening the same to me. Stuck with v2.x as I'm using laravel-echo and it's the last version it supports (https://github.com/tlaverdure/laravel-echo-server/issues/550). With webpack it's really simple as it works flawlessly using require('socket.io-client'), but with vite require() is not defined, and the import way throws the "child_process.spawn" error...
I've tried upgrading socket.io-client to every version, importing with named import, and assigning the io to window.io, but it still doesn't work with laravel-echo as I need to pass a client to the
new Echo({
broadcaster: 'socket.io',
host: import.meta.env.VUE_APP_WEBSOCKET_URL,
client: ??????, //This is what I need, as Vite 3 does not allow the require('socket.io-client') thing
transports: ['websocket', 'polling', 'flashsocket'],
});
Still did not fully test all the cases in real app but you can try doing it in vite.config.ts, seems to work correctly for now 😄
resolve: {
alias: {
"xmlhttprequest-ssl": "./node_modules/engine.io-client/lib/xmlhttprequest.js"
}
}
via: https://github.com/vitejs/vite/issues/4798#issuecomment-925689898
resolve: {
alias: {
"xmlhttprequest-ssl": "./node_modules/engine.io-client/lib/xmlhttprequest.js"
}
}
yes, it's working with laravel-echo and laravel-echo-server. Thanks a lot
OK, so this should fix the issue: https://github.com/socketio/engine.io-client/commit/280de368092b17648b59b7467fa49f2425edcd45
Included in [email protected], which should be transitively imported by [email protected].
Can anyone confirm please?
I can confirm that it magically started working again, so I assume it's because of that.
@gustojs thanks for the feedback :heart:
I think this can be closed now, please reopen if needed.