Comments (13)
import {Manager, Socket} from 'socket.io-client/build/esm';I guess it is not supposed to be imported that way
Socket.io specifies subpath exports. Which with modern module resolution, prevents access to undeclared endpoints. That same module resolution is causing dev-mode webpack to load the debug package. Tree shacking or production builds should not be affected.
This warning should also be present in Vite's strict modes.
Potential solutions to remove the dev warning:
- Provide direct access to the builds with a
build/**/*
export, allowing people to override module resolution. I've seen other projects do this successfully. - Use another debug package that's ESM friendly, I have not found a good one... So I usually end up writing a mini version of it.
- PR a browser friendly Debug update. Should be much easier than trying to do the whole library like I did (terminal colors, inheritance and module resolution acrobatics make it hard). debug-js/debug#786
If your bundler is asking for a development version with good debuggability and source maps, we should provide it what it's asking for.
Feathers removed the debug dependency for Deno support, and it's caused far worse DX.
This is a growing, common, upstream problem, that should ideally have a common solution. The people who maintain Debug are active and receptive... But no-one has the endurance to try making a fully backward compatible ESM update.
We should definitely do 1. 3 would be ideal. But 2 is probably more practical in the short term.
If you publish a debug package under @socketio/debug I'll gladly contribute to it and promote it.
from socket.io-client.
Actually, we provide a debug-free ESM build:
Lines 26 to 30 in 9b235ec
Not sure why ./build/esm-debug/index.js
is resolved in your case, instead of ./build/esm/index.js
.
from socket.io-client.
I'm not really sure what is going on, but it should be very easy to reproduce - just generate a new Angular v16.x project and add this library as a dependency.
b.t.w. If I try to change the import into a specific folder like this:
import {Manager, Socket} from 'socket.io-client/build/esm';
it does not build, comes out with error:
I guess it is not supposed to be imported that way. But the default import results in that warning in the browser console (unless explicitly suppressed in the project's configuration).
from socket.io-client.
OK, I think I found the culprit: due to 781d753 (included in v4.7.0), the build that includes the debug
package (./build/esm-debug/index.js
) is now imported during development.
Which is OK I guess, since that allows to print the debug logs to the console, and it won't be included in the final bundle (which will use ./build/esm/index.js
). @vitaly-t thoughts?
from socket.io-client.
I think, if you have to include that debug
package, then it should not be the default, or it will confuse developers. I would either expose it through an option, or an explicit import, like socket.io-client/debug
, just not the default import, because it breaks ESM tree-shaking and causes warnings.
from socket.io-client.
or it will confuse developers.
Totally agree 👍
just not the default import
Just to be sure to be on the same page, it's not really the default import, it's the import when the "development" condition is met:
Lines 26 to 30 in 9b235ec
Reference: https://nodejs.org/api/packages.html#community-conditions-definitions
import { io } from "socket.io-client/debug"
sounds reasonable.
@FossPrime do you have any thoughts on this?
from socket.io-client.
I have tested v4.7.1, and it seems ok. Well done! Closing it now ;)
from socket.io-client.
This is worse, for everyone... As now we have to manually turn on and off the debug build and run npm i... Rather than the clean automatic operation we had before.
Even in webpack the biggest downside was a small easy to filter warning in dev.
Using the debug build also doesn't turn on debug as you might expect... You still have to configure debug. Which is a bit unexpected when you've already explicitly asked for debug. This is unexpected behavior at the worst time.
The current situation is slightly better than 4.6.x, but worse than 4.7.0. as debug was the primary way to see messages in some environments.
The problem wasn't that the development export was debugable but that the debug logger we and 250M people a week use, has some well known drawbacks.
With 4.7.1 downstream libraries that bundle socketio internally have to ALSO make a /debug export for this to work, with some custom bundling that swaps /debug imports This is the exact problem the debug package and subpath exports were intended to fix.
Proposed solution:
- Implement an ESM debug logger and return the development build.
from socket.io-client.
In this case, maybe a better solution would have been to make use of dynamic import, and an explicit configuration parameter that activates debugging?
Or, perhaps even better solution - move debug
into peerDependencies
, and have this library check at run-time for presence, and only then use it. I think it's the cleanest approach.
from socket.io-client.
move
debug
intopeerDependencies
, and have this library check at run-time for presence, and only then use it
I considered this, and it sounds good, but the compatibility of this solution is not universal.
- Deno has no dynamic import support.
- Yarn 2 and PNPM Plug and Play may bundle debug 100% of the time, as to my knowledge they isolate all modules with a deterministic dependency set, causing the same warning in the webpack-dev server.
Why not use
https://github.com/kat-tax/vslite/blob/1de9b5d678719e6b18151fd6409a32769939e3a9/src/utils/debug.ts With picomatch added, the behavior will be 99% identical to debug, but ESM friendly.
We could even expose that debug logger under the /debug export, and encourage others to use it as a debug package alternative. Tree shaking means it would be nearly free for people doing that.
from socket.io-client.
Deno has no dynamic import support.
See also this:
https://twitter.com/deno_land/status/1643715218793701381?s=20
from socket.io-client.
Might be a new or not default feature... I've never gotten it to work on Deno Playground https://deno.com/deploy/docs/playgrounds
Someone should just do a hard ESM wrap around debug, setup a Cron job for updates and call it a day.
Or better yet, start an NPM organization dedicated to this task... like DefinitelyTyped did with @types/...
from socket.io-client.
With 4.7.1 downstream libraries that bundle socketio internally have to ALSO make a /debug export for this to work
True, but having people open issues here about the webpack warning was not really thrilling either.
- PR a browser friendly Debug update
That would be ideal indeed.
There is also this fork of debug
: https://github.com/milahu/debug-esm
Also: vercel/ms#184
from socket.io-client.
Related Issues (20)
- ESM build for 4.7.2 npm package generates with incorrect package version HOT 6
- socket listen with AbortSignal HOT 2
- React native ios crashes on production with extraHeaders HOT 4
- Add an onMany method to attach a callback to multiple socket events. HOT 2
- Next.js v14.0.0 server with socket.io client doesn't send messages with more than a few characters HOT 5
- Bug: `connect` event will not fire on browser client HOT 6
- Unable to resolve "@socket.io/component-emitter" HOT 7
- Won't switch to polling transport when Websocket transport failed HOT 3
- Property 'of' does not exist on type 'Socket<DefaultEventsMap, DefaultEventsMap>'. HOT 6
- Cannot listen to event dispared in useEffect() Next js 14.0.4 HOT 1
- Encountering 'TransportError' with socket.io-client in React Native Production Mode HOT 1
- Websocket Connection Becomes Unstable - Starts disconnecting and reconnecting after a while of being active HOT 3
- HI, there is a problem about socket.io-client 4.7.0 and netty-socketio 2.0.6. The auth parameter causes the socket connection to fail and returns parse error. HOT 3
- connection error HOT 2
- [BUG] building [email protected] in a typescript based nodejs docker container results in type script error HOT 4
- Minor: Event handler of 'offline' event must be added on the initial evaluation of worker script on Service Worker HOT 1
- v4.7.4 returns `No version specified and unable to automatically determine one` at runtime HOT 2
- socket.io-client not working on Android API 34 - iOS works normally (React Native) HOT 4
- Disabling reconnection while reconnecting isn't working HOT 1
- A parser error causes the socket connection to reconnect but the old connection is not closed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from socket.io-client.