ESM-only

[sakgoyal]

Is there an existing issue for this?

• I've searched for any related issues and avoided creating a duplicate issue.

Description

I know this has been discussed a little in #1886, but I wanted to know your thoughts on shipping ESM only. All platforms support ESM from the past 10 years as far as I understand.

I don't see why we still need to ship CJS. it increases bundle sizes too. why not raise the bar for library support?

[lpinca]

why not raise the bar for library support?

Because it does not add any value. I see no reason to drop support for CJS and upset the majority of users when the library already works with both module systems.

[lemanschik]

it would add a lot of value the code is only never used by your self @lpinca @sakgoyal you do not need esm only anymore just found out Node22+ has native Websocket as object

[lpinca]

The library currently support both CJS and ESM. What is the added value in removing support for CJS? I don't see it. It's like having a software that works on both Linux and Windows. The developer decides to remove support for Window. Is that added value? I don't think so.

[lemanschik]

@lpinca ok let me explain i found out why there are some times issues and sometimes not long story short as soon as you bundle cjs and esm and use the package.json exports and main.

You get diffrent files in diffrent situations with diffrent behavior and object shapes.

Reducing this to ESM only would make it static analyzeable. we would always know what we get then we could if we need to support old node simple npx rollup -p node-resolve -f cjs ws if we need so for eg bundling into electron main iife. Which is a edge case.

i runned into this repo via puppeteer which had problems also with mixed cjs and esm they even hardcoded in esm pathes to cjs.

Sympthoms why do so less ppl complain?

Most ppl use highly automated bundlers the bundlers are clever they know that current coders are not familar with esm so they choose to simple default to cjs and all works magicaly but you get horror code output but as no developer audits his bundle code most do not even see it.

simple look at ppl like https://github.com/sindresorhus

you know him maybe from your dependencys he did the switch to esm only long time ago and all works always well. Offering cjs and esm in the same package is a big antipattern today it leads to a lot of sideEffects in diffrent environments and situations.

also nodejs did add Require(ESM) support in newer versions so there is zero reason to offer cjs

[lemanschik]

also a big no go is the default export it also complicates the stuff using named exports only without default leads to same module shape in CJS and ESM

[lemanschik]

here the puppeteer case:

fixing leads to:

443cb92

as

node_modules/puppeteer-core/lib/esm/puppeteer/node/NodeWebSocketTransport.js:14
const ws = new NodeWebSocket(url, [], {
^

TypeError: NodeWebSocket is not a constructor

---

inside NodeTransport

/**
 * @license
 * Copyright 2018 Google Inc.
 * SPDX-License-Identifier: Apache-2.0
 */
import NodeWebSocket from 'ws';

import type {ConnectionTransport} from '../common/ConnectionTransport.js';
import {packageVersion} from '../generated/version.js';

[lemanschik]

and most evil is because of the exports field inside node and everything that hornors exports i can only import or require the files exposed in export field of the package.json i need to delete the package.json to import eg CJS in ESM

[lemanschik]

OH WOW NOW I SPOTTED The ambigouse part as puppeteer uses typescript with typescript resolve to produce the ESM Output they get CJS :) and that is Broken ESM then.

[lpinca]

Yeah exactly, look at issues opened in Sindre's repos after dropping CJS or node-fetch, etc. Backward compatibility is nice. I don't want any of that negative reaction here. There are no major issues with bundlers that I know of.

also nodejs did add Require(ESM) support in newer versions so there is zero reason to offer cjs

ws still supports Node.js 10.

I don't know what the issue with puppeteer is, but I'm pretty sure it's not related to ws supporting both CJS and ESM.

[lemanschik]

@lpinca i agree with you thats why i stopped to correct the PR here in my special edge case as i can do so i will hardfork anything that uses this ws package and replace it programatical via codemods with the Native Object from Node 22+ and call it a day.

i general tend to hardfork own ESM versions as soon as i run into problems because most old devs will not run into the problems until they switch to a more current ecosystem so do not worry this repo gets bombed as soon as more developers upgrade.

Conclusion

while this is great for node pre 22 you should not use it in current or new projects anymore.

[netizen-ais]

Just a correction to the incomplete information posted before. Latest NodeJS versions do support WebSocket client, but not WebSocket Server as this library does..

[lemanschik]

@netizen-ais your spot on i simple switched to socket.io and eat that dog food. long pooling is needed anyway to paypass nat and routers.