How about integrate all js packages in a monorepo like babel?

[R4M80MrX]

It should be easier to learn the whole structure of the project

[jokester]

+1 but for a different reason.

Currently adapter / parser / server / client code are separate yet effective coupled. I can see use of @ts-ignore here and there to call private methods in other components. If such violations should should be eventually removed, IMO separated repo makes the removal harder.

In fact when I had to touch multiple parts of the repos, the only sensible way I found was to use a monorepo to link the repos (as git submodules) together, like in this branch

[darrachequesne]

@jokester could you please provide some details about those issues?

[jokester]

@darrachequesne Sure. IMO monorepo allow better developer experience and more consistent checks. I'll try to explain by examples.

Imagine that I cloned socket.io repo and opened it in my IDE. Its deps, socket.io-*, engine.io and engine.io-* are published npm packages and their original TS code is unavailable.

If I felt curious about how engine.io code uses wsPreEncoded?: string option, I will have to clone engine.io again if I don't want to look at .d.ts and .js. And even if do that and have all the TS files, the 2 cloned repos don't automatically link together to provide cross-package references like usage search (at least not in VS code or IntelliJ).

This sort of things becomes more awkward if more packages are involved. In fact socket.io-adapter uses that options too.

---

About the coupled code and @ts-ignore: still around the wsPreEncoded option. I used to think it's a leaky abstraction but now it looks to me like something that should get defined in engine.io and exported. However now it's only type-defined in socket.io. engine.io does correctly consumes the option, but in a unchecked way with TS any type. If we really want to move that type definition into engine.io, changes to packages in a monorepo will be easier to coordinate.

I think my point should be, with all the original TS code available and linked, things can be more visible and consistent. This holds for both human and tsc.

That being said I understand it's not a simple or easy decision. socket.io has a long history, I won't be surprised if it started before monorepo became a thing.

[darrachequesne]

@jokester you made some interesting points :+1:

Here we go! The repositories (including their git history of course) have been merged here in this repository.

[jokester]

@darrachequesne thanks!!! The packages are clearly connected in editors now 🚀