v4.3.0 breaks testem

[chriskrycho]

Describe the bug
As of the v4.3.0 release, testem (and therefore all CI runs which use it, so this will shortly be hitting the whole Ember.js community and any others as they upgrade or for runs which check against "drifted dependencies") is failing with the following error:

io.connect is not a function

Inspecting io shows that it is in fact the lookup function (dist).

To Reproduce

Unfortunately, this is a bit involved, and I don't have a good minimal reproduction yet. I will add one later. For now, I will link directly to the relevant bits of testem's source.

Socket.IO server version: 4.3.0

Server

• importing socket.io as `const socketIO = require('socket.io');
• using the imported value as a function

Socket.IO client version: x.y.z

Client

• accessing /socket.io/socket.io.js via <script> tag
• attempting to use io.connect with io as a global

Expected behavior
Given 4.3.0 was a patch release, testem's previous usage should continue to work without issue.

Platform:

• Device: Mac or Linux
• OS: Ubuntu latest, macOS 11.6, etc.

Additional context
I strongly suspect (but haven't yet been able to prove) that this is related to either the engine.io bump, serving ESM, or the intersection of the two.

[chriskrycho]

Update: this is actually an issue in socket-io.client; please feel free to move it!

[chriskrycho]

The change to the shape of the API was introduced here.

[chriskrycho]

A further update: it's not actually clear how or why the build worked previously on the 4.x series. As I'm looking at the shape of the modules exported, it doesn't seem like it should have. I currently suspect that the switch from webpack to Rollup changed the shape of the generated output in a way which happened to break testem; but it looks like the change to the API itself is something testem possibly should have absorbed some time ago.

[chriskrycho]

Confirmed: the output from webpack on v4.2.0 included exports.connect = lookup, here, which meant that users could call io.connect previously; the Rollup output does not have a top-level value of connect defined anywhere on the result of the factory() call Rollup generates.

[chriskrycho]

Not the webpack→Rollup transition's fault—a little further digging back into the change shows what happened: changing from modules.exports to a standard ES named export (here and here respectively) resulted in different compiled output, because you also switched to doing a single default export here rather than re-exporting all the values as a namespace. For equivalent semantics to what you had previously, the contents of lib/browser-entrypoint.ts should be:

export * as io from './index.js';

I'm happy to open a PR to that effect tomorrow.

[darrachequesne]

Arf, sorry for that.

export * as io from './index.js';

is bundled as:

[...]
  var index = /*#__PURE__*/Object.freeze({
    __proto__: null,
    Manager: Manager,
    Socket: Socket,
    io: lookup,
    connect: lookup,
    protocol: protocol
  });

  exports.io = index;

  Object.defineProperty(exports, '__esModule', { value: true });

Which means the io object would be nested: io.io.connect(...)

The following should work though:

import { io, connect } from "./index.js";

io.connect = connect;

export default io;

What do you think?

[chriskrycho]

That could work, but in that case (for the sake of backwards compatibility) we should make sure we do that for all the functions which were previously exported that way. Testem also relies on having io.Manager available, for example. I wonder if it makes sense to make sure that lookup/io has that before exporting in the source module, rather than trying to handle it on the entry point side.

[chriskrycho]

Aside: JavaScript is such shenanigans. The fact that an export can be both a function and a namespace is just… 🙃😩🤪🥴

[chriskrycho]

I've pushed an update to the PR which manually recreates the namespace in the source module, while preserving the nice new ES module exports.

[darrachequesne]

This should be fixed by socketio/socket.io-client@8737d0a, which was included in ̀[email protected].

[SergeAstapov]

@chriskrycho @darrachequesne I maybe missing something, as far as I can see we need a new release of socket.io because client is bundled with socket.io, in the client-dist folder.

E.g. Testem.js does not depend on socket.io-client, it only has socket.io in it's dependencies

[chriskrycho]

@SergeAstapov yeah, you're correct—given the re-bundling pattern used socket.io itself also needs a release. @darrachequesne, mind cutting that on Monday? Thanks!

[hoIIer]

@chriskrycho assuming ember-cli will need to cut a release once testem updates as well? (currently broken in latest 3.28)

[chriskrycho]

Shouldn't. The CI breakage is just from the Ember CI defaults of including a run which lets all dependencies resolve to their latest legal version (using --no-lockfile), precisely so we catch issues like this early. Once the release is out, all of the CI jobs should start passing again.

If you're seeing the CI builds fail from this issue (as I have on ember-modifier), it's almost certainly because of a cache issue which is causing other runs to inherit the bad version even though per the lock file they shouldn't. That should also get fixed (via the same bad cache behavior!) once socket.io cuts 4.3.1. I'm going to poke at the CI config a bit on Monday and see if there's something we need to tweak for the GH Actions defaults to make sure that part doesn't become a problem again in the future.

[hoIIer]

ok gotcha thanks for the work & update

[darrachequesne]

@chriskrycho done! https://github.com/socketio/socket.io/releases/tag/4.3.1