Socket.io: Roteiro para v3

Parece um ótimo plano.

Estou mudando de nodejs para golang e descobri que não há implementação de socket.io 2.
https://github.com/googollee/go-socket.io/issues/188

O que você acha do suporte do servidor golang para v3? Será um prazer participar deste desenvolvimento.

@theromis você está falando sobre um cliente golang (que se conectará ao servidor Node.js) ou um servidor golang real? (Acho que algum trabalho foi feito aqui também: https://github.com/graarh/golang-socketio)

@darrachequesne Obrigado pela resposta rápida, sim, estou falando do golang-socketio do lado do servidor.
O projeto mencionado por você está quase morto (último commit há mais de um ano).
https://github.com/googollee/go-socket.io projeto procurando mantenedor.
E nenhum deles suporta socket.io v2.
Eu pensei que os maiores desenvolvedores do nodejs socketio originais poderiam estar interessados ​​no desenvolvimento do golang também :)

O cliente Java atualizado também seria bom.

Um pacote socket.io para o servidor swift como https://github.com/vapor também seria muito bom, pois já existe um cliente swift.

Parece que se o socket.io do lado do servidor for escrito em alguma linguagem nativa como C/C++, ele pode ser usado em todos os lugares, incluindo nodejs, golang, java, rust e o que for ...
O que há de errado com essa abordagem?
Minha opinião pessoal socket.io é como o padrão de fato para o mundo moderno. Por que não torná-lo ideal?

Uma coisa que sempre me incomodou em socket.io que poderia ser abordada no próximo grande lançamento poderia ser https://github.com/socketio/socket.io/issues/2124 e https://github.com /socketio/socket.io/issues/2343

Houve uma inconsistência histórica no tratamento de namespaces e middlewares.
Além disso, o client emitindo um evento reconnect faz mais sentido na minha opinião, depois de se conectar ao namespace ao invés de ser apenas o evento de reconexão do gerente... Por exemplo , se houver algum erro de autenticação em um middleware de sub namespace, o cliente ainda receberá um evento de reconexão que eu acho que é contra-intuitivo.

A partir da versão 10.5 do nó, há um novo Worker Threads, que está atualmente em estado experimental, mas quando lançado, acho que pode ser uma maneira melhor de usar o socket.io em vez de usar o servidor redis.

Pró:

• menos dependência (redis)
• suporte nativo de multi threading
• mais controle

Vigarista:

• só funcionará a partir dessa versão do nodejs que liberar o thread de trabalho (10.x || 11). Mas isso pode ser tratado.

@Two é interessante! Funcionaria para trabalhadores no mesmo host, mas e quanto a vários hosts?

@perrin4869 boa ideia :+1:

Deixei muitas ideias aqui: #3311 por favor leia :) Vou fechar essa e continuar a discussão aqui.

@MickL você teria algum tempo para migrar o repositório socket.io para Typescript, como exemplo?

Receio que meu conhecimento de tecnologia de rede e segurança da informação seja limitado. Eu confio em frameworks de alto nível como Express ou Socket.io.

Tanto quanto eu vejo, socket.io já está escrito OOP e bem documentado, então seria fácil simplesmente portá-lo. Minha ideia era ser o mais modular possível para que alguém como eu pudesse contribuir com mais facilidade e o cliente fosse treeshakable. Também ficar mais reativo pode ser uma ideia para tornar as coisas mais simples. De qualquer forma, não estou o suficiente no código, então ambas as idéias podem não fazer sentido neste projeto.

@darrachequesne é uma boa pergunta. vou pensar nisso.

Exija o Nodejs 8 e superior, pois as versões anteriores estão em manutenção na melhor das hipóteses, consulte https://nodejs.org/en/about/releases/ , pelo menos o nodejs 4 deve ser descartado (percebi em .travis.yml que você suporta isto)

O trabalho relacionado ao 3.0 começou em alguma filial/repo? Só verificando se tem um lugar para ficar informado sobre como está indo ou contribuindo.

Eu gostaria de ver um suporte aprimorado para tratamento de erros no lado do servidor. Isso foi levantado em algumas outras questões, mas, mais especificamente, seria ótimo se:

1. Havia suporte para um middleware de tratamento de erros personalizado além do padrão. Isso pode se parecer com o do Express (que pode ser anexado como o último na cadeia de app.use() , semelhante a socket.use() , middlewares): https://expressjs.com/en/guide/error -handling.html

O problema, no momento, é que não há como adicionar nenhum tipo de rastreamento ou registro a um erro uma vez que tenha sido nexted .

1. Além disso, como o namespace 'error' está na lista negra, socket.emit('error', err) não será ouvido pelo cliente), não posso emit um erro de algum lugar no servidor que não tenha fácil acesso a next() (ou seja, de dentro de socket.on('event') ). Isso dificulta a criação de uma solução uniforme de tratamento de erros.

2. next(err) deve despachar um objeto Error em vez de uma string. Eu entendo que existe uma solução para isso (https://github.com/socketio/socket.io/issues/3371) adicionando uma propriedade mágica .data a qualquer objeto que você chame next() em. Isso não está documentado, no entanto, e não é intuitivo.

De um modo geral, next(err) parece uma caixa preta desnecessária de capacidade de tratamento de erros muito limitada.

Obrigado por seu trabalho duro, e mantê-lo!

@darrachequesne Alguma atualização na v3 sendo uma realidade? Não vejo nenhum progresso nisso desde 2018.

Uma pequena atualização: meu contrato atual foi atualizado recentemente e devo poder dedicar um dia por semana (1/5) à manutenção do projeto. Assim, o trabalho na v3 deve ser retomado em breve.

Muito ansioso para ajudar neste projeto de uma forma ou de outra.

Se houver uma maneira de identificar como posso fazer isso, avise-me - eu só não quero corrigir as coisas para que elas não sejam mescladas! Então, prefiro esperar por alguma orientação, se for necessária ajuda. Saúde

• compressão (gzip, zlib, defalte/inflate)
• mecanismo de retrabalho de envio de dados binários (2 pacotes agora... texto ws e binário ws)
• enviar metadados na conexão (usar compactação?)
• codificadores/codificadores como plugins incluem um personalizado (messagepack, protobuf, etc), podemos usar genéricos se o código for reescrito para texto datilografado
• fixação de certificados (servidor/lado do cliente)

@blackkopcap

compressão (gzip, zlib, defalte/inflate)

A compactação já é suportada (https://github.com/socketio/engine.io/blob/a05379b1e87d2e4cde40d3e30b134355883f4108/lib/transports/polling.js#L249-L298). A compactação WebSocket ( perMessageDeflate ) será desabilitada por padrão na v3, pois requer muita memória extra.

mecanismo de retrabalho de envio de dados binários (2 pacotes agora... texto ws e binário ws)

Concordo plenamente. Cartão adicionado aqui

enviar metadados na conexão (usar compactação?)

Eu não tenho certeza se entendi. Você poderia explicar o caso de uso?

codificadores/codificadores como plugins incluem um personalizado (messagepack, protobuf, etc), podemos usar genéricos se o código for reescrito para texto datilografado

Você já deve ser capaz de fornecer seu próprio analisador, como socket.io-msgpack-parser

fixação de certificados (servidor/lado do cliente)

:+1:, adicionado aqui .

@michaelegregious

1. Havia suporte para um middleware de tratamento de erros personalizado além do padrão. Isso pode se parecer com o do Express (que pode ser anexado como o último na cadeia de app.use() , semelhante a socket.use() , middlewares): https://expressjs.com/en/guide/error -handling.html

Isso seria ótimo mesmo. Adicionado aqui

1. Além disso, como o namespace 'error' está na lista negra ( socket.emit('error', err) não será ouvido pelo cliente), não posso emit um erro de algum lugar no servidor que não tenha fácil acesso a next() (ou seja, de dentro de socket.on('event') ). Isso dificulta a criação de uma solução uniforme de tratamento de erros.

Não tenho certeza do que poderíamos fazer. Você tem uma sugestão?

1. next(err) deve despachar um objeto Error em vez de uma string. Eu entendo que existe uma solução para isso (https://github.com/socketio/socket.io/issues/3371) adicionando uma propriedade mágica .data a qualquer objeto que você chame next() em. Isso não está documentado, no entanto, e não é intuitivo.

Concordo totalmente :+1: , adicionado aqui

Já lançamos o Engine.IO v4, que será incluído no Socket.IO v3. Você pode encontrar as notas de lançamento aqui .

Eu adicionei o que pude encontrar neste tópico ao projeto aqui , para dar uma visão geral do progresso. Não hesite em comentar!

Aqui está o que eu tinha em mente para corrigir https://github.com/socketio/socket.io/issues/2124

O cliente agora enviará um pacote CONNECT quando quiser obter acesso ao namespace padrão ( / ) (sem conexão implícita).

O que significaria que os middlewares registrados para o namespace padrão não se aplicarão mais aos clientes que desejam obter acesso a um namespace não padrão

// server-side
io.use((socket, next) => {
  // not triggered anymore
});

io.of('/admin').use((socket, next => {
  // triggered
});

// client-side
const socket = io('/admin');

Do lado do cliente, acho que também devemos fazer uma distinção clara entre a opção query para o Manager (que está incluída nos parâmetros de consulta) e a opção query para o Socket (que é enviado no pacote CONNECT ).

Agora mesmo:

const socket = io('/admin', {
  query: {
    abc: 'def'
  }
});

resulta em solicitações como GET /socket.io/?transport=polling&abc=def e também um pacote CONNECT como { "type": 0, "nsp": "admin?abc=def"}

Além disso, como não há pacote CONNECT para o namespace padrão, o query do Socket é ignorado nesse caso.

Proponho renomeá-lo para authQuery .

const socket = io({
  query: {
    abc: 'def'
  },
  authQuery: {
    abc: '123'
  }
});

resultaria em solicitações como GET /socket.io/?transport=polling&abc=def e um pacote CONNECT como { "type": 0, "nsp": "/", "data": { abc: '123' } }

@perrin4869 faria sentido?

Edit: em relação a compensações, haverá mais solicitações HTTP na inicialização ...

Server > Client: Engine.IO handshake
Client > Server: Socket.IO connect
Server > Client: Socket.IO connect

Enquanto atualmente temos:

// without middleware on the default namespace (only 1 GET request)
Server > Client: Engine.IO handshake + Socket.IO connect
// with at least a middleware (2 GET requests)
Server > Client: Engine.IO handshake
Server > Client: Socket.IO connect

@darrachequesne Obrigado por levar isso em consideração! É bom ter um fechamento aqui, finalmente capaz de simplificar o código que eu tinha na época :D
Já faz muito tempo, então não me lembro exatamente, mas isso parece a solução que eu estava procurando
Por curiosidade, qual o motivo das trocas?

Seguindo a ideia de como as formas js funcionam: https://web.archive.org/web/20200201163000/https://mathiasbynens.be/notes/shapes-ics . Para melhorar o desempenho, não seria melhor usar arrays para armazenar referências para conexões de soquete? Mais e mais conexões, inúmeros ids e usando objetos para fazer isso a cada nova conexão, uma nova forma é gerada e mais memória é consumida, dependendo do tempo de vida de um nó e do número de conexões que ele pode ter, isso provavelmente terá algum impacto negativo no desempenho.

@perrin4869 as compensações vêm da implementação atual, pois primeiro estabelecemos a conexão Engine.IO e, em seguida, prosseguimos com a conexão Socket.IO. O que dá, se o transporte de sondagem longa HTTP estiver ativado (que é o padrão):

• uma solicitação HTTP GET para recuperar o handshake Engine.IO
• uma solicitação HTTP POST para enviar o pacote Socket.IO CONNECT
• uma solicitação HTTP GET para recuperar o pacote Socket.IO CONNECT do servidor
• e, em seguida, a atualização para WebSocket

Mas certamente poderia ser melhorado. Para referência, a alteração foi implementada aqui e aqui .

Além disso, o evento reconnect não será mais emitido pela instância do Socket (client-side) ( aqui ).

@ferco0 agora usaremos um Map em vez de um objeto simples (https://github.com/socketio/socket.io/commit/84437dc2a682add44bb57d03f703cfc955607352). Seu comentário ainda se aplica, nesse caso?

[email protected] e [email protected] foram publicados :fire:

Algumas notas:

• a API pública não muda muito (alguns métodos foram removidos, veja aqui e aqui para referência)
• a base de código foi migrada para o TypeScript, mas faltam algumas tipagens, principalmente no lado do cliente.
• as mudanças de última hora no Engine.IO v4 (listadas aqui ) foram incluídas
• o tamanho do pacote do cliente aumentou um pouco, apesar de ter menos dependências, vou me aprofundar nisso

Qualquer feedback é bem-vindo!

@darrachequesne tudo bem.

@darrachequesne Muitos projetos de código aberto npm tentam diminuir a quantidade de dependências. É um pouco de uma tendência dentro da comunidade. O principal motivo é que muitas organizações exigem a verificação de licenças de todas as dependências usadas quando são usadas em projetos, para não se deparar com problemas legais. Ter menos dependências ajuda com isso, é claro. Como exemplo, o Helmet (um ótimo pacote de segurança para o servidor da Web Express) foi para uma instalação de dependência zero na última versão 4.0.

Com isso em mente, existe um plano para diminuir a quantidade de dependências no socket.io na versão 3?

@thernstig essa é uma boa pergunta! De fato, tentamos reduzir o número de dependências no Socket.IO v3:

npm i [email protected] => 48 packages
npm i [email protected] => 33 packages

npm i [email protected] => 37 packages
npm i [email protected] => 20 packages

Aqui está a árvore de dependências do servidor:

[email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ └── [email protected]
├── [email protected]
├─┬ [email protected]
│ ├── @types/[email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected] deduped
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └─┬ [email protected]
│ │ │   └── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ └── [email protected] deduped
└─┬ [email protected]
  ├── [email protected] deduped
  └── [email protected] deduped

Acho que só precisamos da pasta dist/ socket.io-client do pacote socket.io-client, então pode fazer sentido criar um socket.io-client-dist sem dependências. O que você acha?

Nota: tomada. [email protected] e socket. [email protected] foram publicados

Adicionei alguns exemplos com módulos ES e TypeScript .

@darrachequesne deixo isso inteiramente a seu critério 😄

@michaelegregious em relação ao seu comentário , sei que já faz um bom tempo, mas você tinha uma API específica em mente?

Concordo que a API atual poderia ser melhorada. Ele foi implementado como uma forma de ter um ouvinte abrangente (discutido aqui ), e não com o tratamento de erros em mente.

Também poderíamos adicionar uma maneira de avisar os usuários sobre eventos não tratados (respostas 404 no Express, http://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses).

@darrachequesne ótimo ouvir seu trabalho na próxima versão do socket.io !! Agradecemos antecipadamente por todo o seu trabalho nesta biblioteca.

Estou testando o socket. [email protected] e socket. [email protected] e estou tentando usar a nova sintaxe para ingressar em uma sala e emitir para soquetes nessa sala.

Não consigo fazer com que o servidor emita para o soquete do cliente usando seu exemplo no arquivo de log de alterações.

socket.join("room1"); io.to("room1").emit("hello");

Em anexo estão as capturas de tela que mostram o arquivo js do soquete sendo usado no cliente e o código para o servidor node.js

arquivo js do lado do cliente

evento socket.on do lado do cliente

sintaxe de junção do lado do servidor dentro do io.on("connect",

Eu tentei todos os métodos na última cena para fazê-lo emitir para o cliente e nada funciona.

Por favor, deixe-me saber se você precisar de mais informações.

Obrigada

@darrachequesne Fiz downgrade para 3.0.0-rc2 e entrei na sala usando join com o método de retorno de chamada chamado "room1", que é acionado, mas nenhum dos eventos de emissão é enviado ao cliente

socket.join("room1", () => { console.log('old way to join'); io.to("room1").emit("hello", {}); io.in("room1").emit("hello", {}); });

Também desinstalei o 3.0.0-rc2 e instalei o socket.io 2.3.0 para Servidor e Cliente e confirmei que o código acima funciona conforme o esperado. Então eu acredito que algo está quebrado com as versões 3.0.0 rc

@szarkowicz Hmm... Não consigo reproduzir o comportamento que você está descrevendo: https://github.com/socketio/socket.io-fiddle/tree/issue/v3

O código a seguir parece funcionar como esperado:

socket.join("room1");

io.to("room1").emit('hello', 1, '2', {
  hello: 'you'
});

Você recebe algum erro no console? Você recebe um evento connect no lado do cliente?

@darrachequesne obrigado por confirmar. Eu o rastreei de volta ao uso do redisAdapter causando o problema. Depois de comentar o código a seguir, a versão rc3 do socket.io funciona conforme o esperado.

let redisAdapter = require('socket.io-redis');
io.adapter(redisAdapter({ host: 'localhost', port: 6379 }));

Você já tentou usar redis com a v3 do socket.io?

Obrigado

@szarkowicz sim, você está absolutamente certo, o adaptador Redis precisa ser atualizado para ser compatível com o Socket.IO v3, ele será atualizado logo após a versão 3.0.0 (que deve ser em breve).

De qualquer forma, muito obrigado pelo feedback :+1:

@darrachequesne ok soa bem!!! Só não vou usar if por enquanto e continuarei testando sem ele.

Você tem um momento em que acha que a v3 será lançada?

Não se preocupe - obrigado novamente por me retornar e por trabalhar em todos os aprimoramentos para a próxima versão!!

@darrachequesne Muito obrigado por essas atualizações! Desculpe minha demora na resposta! Não estamos usando socket.io no meu projeto atual (embora possamos integrá-lo no futuro), mas a solução que usei no meu último projeto foi usar socket.emit('err', err) em vez de usar o namespace privilegiado socket.emit('error', err) .

Aqui está a nota que coloquei no readme do nosso aplicativo para explicar o problema:

#### Error Handling Patterns
Most of the communication between client and server in the app happens via `socket.io`. For server-side error-handling, `socket.io` exposes [Express](https://expressjs.com/en/guide/error-handling.html)-like middleware via `socket.use(socket, next)`. Middlewares can be chained to separate concerns for authentication, logging, etc.

Unlike `Express`, however, `socket.io`'s native `next(err)` does not support addition of custom error handlers. Calling `next(err)` immediately breaks out of the middleware chain. Additionally, the privileged `error` namespace (emitted by `next(err)` and received by the client via `socket.on('error', err)`) is not available for use via the standard `socket.emit('error', err)` on the server. 

For these reasons, the server instead emits all errors to the client via `socket.emit('err', err)`. We use a `./CustomError` Class (inheriting from the native JS Error) to namespace our errors, and then rely on a switch to properly route errors on the client. (This also allows us to track and log outgoing errors via custom middleware on the server.)

Então, pensando nisso novamente, se você já incorporou a capacidade de adicionar um middleware personalizado a next(err) , também é possível permitir o uso do namespace socket.emit('error', err) para uso manual no servidor?

Estou olhando para esse código e todos os meus manipuladores de eventos se parecem com isso (se for útil ver):

    socket.on('quotes', async (params) => {
      try {
        await dispatchQuotes(socket, params);
      } catch (err) {
        socket.emit('err', err);
      }
    });

Oh! Mais uma coisa que estou lembrando. Aqui está uma solução que eu costumava monitorar eventos de saída para fins de registro/tratamento de erros:

  ioServer.on('connection', (socket: Socket) => {
    const emitter = socket.emit;

    // We modify socket.io's native 'emit' method to monitor outgoing
    // events, since socket.use() (middleware) only tracks incoming events.
    socket.emit = (...args: any) => {
      emitter.apply(socket, args);
      outgoingErrorMiddleware(socket, args, app);
    };

etc.

Aqui está a maneira como usei o middleware de saída, se for útil ver:

export function outgoingErrorMiddleware(socket: SocketIO$Socket, packet: Packet, app: App) {
  const [eventName, err] = packet;
  const { metrics } = app.locals;
  if (eventName === 'err') {
    logger.error(err);
    metrics.errors += 1;
  }
}

Obrigado novamente por todo seu trabalho duro! Tentarei responder mais rápido da próxima vez.

1. Além disso, como o namespace 'error' está na lista negra ( socket.emit('error', err) não será ouvido pelo cliente), não posso emit um erro de algum lugar no servidor que não tenha fácil acesso a next() (ou seja, de dentro de socket.on('event') ). Isso dificulta a criação de uma solução uniforme de tratamento de erros.

Não tenho certeza do que poderíamos fazer. Você tem uma sugestão?

@michaelegregious obrigado pelos exemplos que você forneceu. (e não há problema para o atraso!)

Tecnicamente falando, não tenho certeza se podemos detectar os erros lançados por um ouvinte assíncrono:

socket.on("test", async () => {
  throw new Error("catch me?");
});

try {
  socket.emit("test");
} catch (e) {
  // won't catch the error
}

Então, acho melhor deixar o usuário lidar com os erros sozinho, seja com o código que você forneceu ( socket.emit("err", err); ), ou com uma função de reconhecimento:

socket.on('quotes', async (params, cb) => {
  try {
    await dispatchQuotes(socket, params);
  } catch (err) {
    cb(err);
  }
});

O que você acha?

O que está atualmente implementado para v3:

• "error" é renomeado como "connect_error" e está restrito apenas ao erro de middleware de namespace:

// server
io.use((socket, next) => {
  next(new Error("unauthorized"));
});
// client
socket.on("connect_error", (err) => {
  // err instanceof Error === true
  // err.message === "unauthorized"
})

O que também significa que "erro" não é mais um nome de evento reservado.

• socket.use() é removido e substituído por socket.onAny() (servidor e cliente)

// server
io.on("connect", (socket) => {
  socket.onAny((event, ...args) => {

  });
});

// client
socket.onAny((event, ...args) => {
  // ...
});

Parece bom para você? Você tem alguma sugestão?

Olá a todos!

soquete. [email protected] e socket. [email protected] estão fora. Você pode testá-los com npm i socket.io<strong i="10">@beta</strong> socket.io-client@beta .

Planejamos lançar o 3.0.0 na próxima semana. O guia de migração foi criado: https://socket.io/docs/migrating-from-2-x-to-3-0/ (faltam alguns detalhes, como os eventos reservados no lado do cliente)

Como de costume, comentários são bem-vindos!

Tenho uma dúvida, não sei se aqui é o lugar certo para isso, mas é possível definir o socket id na conexão, por exemplo, usar o client id vindo do db? Alterar a prop "id" do objeto socket no middleware de conexão faz a sincronização com o cliente?

@darrachequesne Obrigado pela atualização do RC4.
Com a versão 3.0.0.rc4 - 2 Perguntas:

1. Qual é a melhor maneira de obter o número ou a lista de soquetes (clientes) em uma sala?
2. Qual é a melhor maneira de obter uma lista de todos os quartos atuais?

Vou fazer muitos testes nos próximos dias com o rc4.

Obrigado novamente por todo seu trabalho duro.

@ferco0 não é possível no momento, o Socket#id é gerado aqui . No seu exemplo (ID do cliente do db), o que acontece se o mesmo usuário abrir uma nova guia? (já que o Socket#id deve ser único)

@szarkowicz

1. Qual é a melhor maneira de obter o número ou a lista de soquetes (clientes) em uma sala?

io.allSockets() => obter todos os ids de soquete (funciona com vários servidores) (bem, assim que o adaptador Redis for atualizado)
io.in("room1").allSockets() => obter todos os ids de soquete na sala

(foi nomeado io.clients() no Socket.IO v2)

1. Qual é a melhor maneira de obter uma lista de todos os quartos atuais?

Atualmente, não há API para isso, além de investigar o adaptador: io.of("/").adapter.rooms ( aqui )

Além disso, o adaptador Redis possui um método allRooms , mas não foi refletido na API pública.

Ok, realmente aprecio as informações para obter os clientes e os quartos para Redis e não Redis. Provavelmente começarei a testar apenas com o socket.io v3 até que o adaptador Redis seja atualizado.

Migre para o webpack 4 (ou outro bundler, se necessário)

Você pode dar uma olhada em https://github.com/formium/tsdx como alternativa.
Eu queria empurrar uma reescrita de socket.io & engine.io no Typescript há alguns meses usando tsdx, mas não consegui encontrar tempo para fazê-lo :smile:

:rocket: Socket.IO v3.0.0 foi lançado! :rocket: As notas de lançamento podem ser encontradas aqui: https://socket.io/blog/socket-io-3-release/

Obrigado a todos os envolvidos neste tópico por suas ideias/feedback :heart:

@darrachequesne , tudo isso faz sentido para mim. Esqueci desse assunto re. middlewares assíncronos (no meu projeto atual, criamos uma função wrap() para cada rota Express para lidar com esse problema exato, para que nenhum erro passe despercebido).

Obrigado por todas as melhorias!

Parece bom para você? Você tem alguma sugestão?

middlewares assíncronos

@michaelegregious você poderia abrir uma solicitação de recurso para isso? Obrigado!

Vou encerrar este assunto agora. Discussão sobre o lançamento: https://github.com/socketio/socket.io/discussions/3674