Missing dependency `socket.io-adapter` in `@socket.io/redis-streams-emitter` 0.1.0

[fjeldstad]

The socket.io-adapter dependency is not listed in package.json of @socket.io./redis-streams-emitter. This causes consuming applications to crash when trying to load the emitter package.

This applies to version 0.1.0 of the package.

[fjeldstad]

As a side note, for reliability it could be good to have CI run isolated per package, it would help guarding against issues like this one.

[darrachequesne]

Good catch! This should be fixed by 7617707, included in version 0.1.1.

Regarding the CI, that's an interesting idea. A few open questions:

• should we use one workflow per package? one job? Or we use the matrix field?
• how to express the dependencies between packages? (i.e. socket.io-client depends on engine.io-client and socket.io-parser)

With one workflow per package, we could use path-based triggers:

on:
  push:
    paths:
      - 'packages/engine.io-client/**'
      - 'packages/socket.io-parser/**'
      - 'packages/socket.io-client/**'
// run socket.io-client tests

[fjeldstad]

Good catch! This should be fixed by 7617707, included in version 0.1.1.

Regarding the CI, that's an interesting idea. A few open questions:

• should we use one workflow per package? one job? Or we use the matrix field?
• how to express the dependencies between packages? (i.e. socket.io-client depends on engine.io-client and socket.io-parser)

With one workflow per package, we could use path-based triggers:

on:
push:
paths:
- 'packages/engine.io-client/'
- 'packages/socket.io-parser/'
- 'packages/socket.io-client/**'
// run socket.io-client tests

As you say there are several possibilities. It can be tedious to maintain one workflow per workspace, otherwise that is a straightforward solution.

I have had good results using the tooling provided by Turborepo for determining the affected workspaces in a PR; you can run turbo run build --affected --dry-run=json (or something close to that) and parse the output for a list of workspaces, then use the matrix approach to run tests for each in isolation (with npm ci --workspace ${{ affected_workspace_from_turbo_output }}-ish). (Note that you don't have to use Turborepo for other things for this to work, but you do need a minimal turbo.json.)

Using a matrix with all workspaces hardcoded is a good tradeoff I would say; you get the isolation between packages but also simplicity of not trying to detect affected workspaces. If it is acceptable to run all tests (all packages) for every change then I would recommend that approach.