Socket.io-client: Falha ao carregar o arquivo no IE

O mesmo aqui em v2.3.0 e IE 11

O mesmo aqui em v2.3.0 e IE 11

Voltamos para 2.2.0 e está funcionando bem.

Eu também reverti para 2.2.0 e funciona bem. Parece que o código exportado pelo módulo não é ES5 válido.

Bem, deve ter sido transpilado por babel ... Vou dar uma olhada nisso.

Le jeu. 26 set. 2019 à 11:09, orangejuice [email protected] a
écrit:

Eu também reverti para 2.2.0 e funciona bem.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/socketio/socket.io-client/issues/1328?email_source=notifications&email_token=ADDNSFI5LWY4MJXY24WZNNLQLR333A5CNFSM4I2MYYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7U4IVQ#issuecomment-535413846 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADDNSFNC7OUW4Z3BEWLSNRLQLR333ANCNFSM4I2MYYBA
.

Isso aconteceu depois de atualizar o debug de v3 para v4, que usa o operador spread em seu distribuível.
Muitas vezes, os node_modules são excluídos da compilação do babel por motivos de desempenho.

Também tenho isso no IE11.

"SyntaxError: Syntax error
   at ../node_modules/socket.io-client/node_modules/debug/src/browser.js (http://192.168.86.48:3000/static/vendors~vehicle-Vehicle.jsx.eb6d2ebd6bfc7172757c.js:510:1)
   at __webpack_require__ (http://192.168.86.48:3000/static/client.js?1571655164758:107:12)
   at eval code (eval code:7:1)
   at ../node_modules/socket.io-client/lib/url.js (http://192.168.86.48:3000/static/vendors~vehicle-Vehicle.jsx.eb6d2ebd6bfc7172757c.js:488:1)
   at __webpack_require__ (http://192.168.86.48:3000/static/client.js?1571655164758:107:12)
   at eval code (eval code:6:1)
   at ../node_modules/socket.io-client/lib/index.js (http://192.168.86.48:3000/static/vendors~vehicle-Vehicle.jsx.eb6d2ebd6bfc7172757c.js:444:1)
   at __webpack_require__ (http://192.168.86.48:3000/static/client.js?1571655164758:107:12)
   at eval code (eval code:55:22)
   at ./shared/components/catalogue/ValuationCatalogue.jsx (http://192.168.86.48:3000/static/vehicle-Vehicle.jsx.b7e97db41986fa53caa6.js:344:1)"

Linhas afetadas

/**
 * Invokes `console.log()` when available.
 * No-op when `console.log` is not a "function".
 *
 * <strong i="9">@api</strong> public
 */
function log(...args) {
    // This hackery is required for IE8/9, where
    // the `console.log` function doesn't have 'apply'
    return typeof console === 'object' &&
        console.log &&
        console.log(...args);
}

Na verdade, não tem muito a adicionar, pois foi identificado como código não transpilado.

O mesmo aqui em v2.3.0 e IE 11

e iOS9 Safari

Esta é uma mudança significativa em um lançamento pontual que também foi atualizado automaticamente. Para quem ainda suporta o IE11 isso é bem sério, demoramos alguns dias para perceber.

Quanto tempo você espera que eles levem para corrigir o problema?

este problema está relacionado a debug:4.1.0 Eles já substituíram o método, mas ainda não há nenhuma nova compilação onde esse problema seja corrigido.

correção para socket.io-client e engine.io-client seria substituir a versão atual debug pela versão 4.0.1 .

Infelizmente, parece que o mantenedor de debug não está disposto a ouvir nosso problema: https://github.com/visionmedia/debug/issues/668#issuecomment -576262641

Olá @darrachequesne :)

Você pode fixar o pacote debug de socket.io-client em 4.0.1 ? Obrigado!

Nesse ínterim, tentei abordar o mantenedor de debug e pedi-lhe que repensasse sua escolha de não transpilar mais o pacote para o código ES5 : https://github.com/ visionmedia / debug / issues / 745

Já ouvi o problema mil vezes. Eu ouvi isso desde que o problema foi criado. Transpile seu aplicativo se quiser que funcione em navegadores arcaicos; debug é apenas a primeira de muitas dependências que você encontrará escritas e publicadas como módulos ES6.

Muitas vezes, os node_modules são excluídos da compilação do babel por motivos de desempenho.

Isso não significa que os mantenedores dos pacotes devam manter seu código preso à idade da pedra. O ecossistema javascript é lento, sim, mas é ainda mais lento quando, por exemplo, o IE11 nos mantém retidos. A razão pela qual debug é muito escolhido é porque ele é um dos 10 principais pacotes mais dependentes e, portanto, é geralmente um dos primeiros pacotes a encontrar erros ou problemas, embora centenas de outras dependências o deixem lento para baixo também.

Se você não acredita em mim, transpile manualmente debug em seu node_modules e tente empacotar seu aplicativo novamente. Muito provavelmente, dependendo do tamanho do seu aplicativo, o processo de empacotamento falhará em outro lugar.

Se você tiver um problema com a eficiência do Babel, abra um problema no Babel. Se você tiver um problema com o CRA não realizar a transpilação adequada, abra um problema com o CRA.

Eu não quero parecer desdenhoso; isso simplesmente não é um problema de debug .

Pelo que dizem neste link aqui . Parece ser um problema de configuração do babel, talvez se o pessoal mudar a configuração dentro do socket-io-client possa resolver o problema.

Correto; essa é a resposta oficial da equipe de Babel. Por favor, leve seus problemas para lá.

Qual resposta oficial? O problema vinculado era sobre o babel não transpilar os pacotes selecionados de node_modules quando configurado para, e isso foi corrigido.

Socket.io-client nem mesmo usa o babel para transpilar. Ele só usa o webpack para agrupar todas as dependências em um único distribuível.

Portanto, agora, se o socket.io-client deve ser suportado em navegadores mais antigos, ele precisa de uma etapa de transpilação durante a construção ou precisa fazer o downgrade ou substituir o debug.

Publicar pacotes para a web que precisam de transpilação não é tão comum. Ao longo dos anos de transpilação, encontrei-o apenas algumas vezes, mesmo em projetos com literalmente GBs de dependências em node_modules. Até agora, cada mantenedor foi bom o suficiente para tratá-lo como um bug ...

Esta é a resposta a que me referia:

Eu concordo que este não é um bug de debug , mas um problema de como o Babel foi configurado.

Se você configurar o Babel para transpilar módulos de nó, mas ainda não estiver funcionando, forneça um repositório mínimo que eu possa clonar para investigar.

Então agora, se socket.io-client deve ser suportado em navegadores mais antigos, ele precisa. . . uma etapa de transpilação

Correto. Esse é o estado do desenvolvimento web moderno.

com literalmente GBs de dependências em node_modules

Este é o verdadeiro problema. Não debug escolhendo não transpilar. Ao usar módulos ES6, geralmente isso não é um problema porque seu aplicativo apenas agrupará as dependências que usa e, portanto, apenas transpilará as dependências que usa. As pessoas fazem isso com grande efeito todos os dias.

Até agora, cada mantenedor foi bom o suficiente para tratá-lo como um bug ...

Usar versões perfeitamente válidas de Javascript não é um bug.

Dizer transpile node_modules em vez de publicar um pacote que suporte tantos ambientes ativos quanto possível é um dedo médio para qualquer pessoa que dirige um negócio.
Preciso selecionar cuidadosamente cada pacote para transpilar, já que transpilar tudo de node_modules mais do que quadruplica o tempo de construção de alguns projetos - às vezes de vários minutos a uma hora. Ninguém tem tempo para isso.
Hoje, mais pessoas ainda usam o IE11 do que o Firefox. O IE11 ainda é compatível com a Microsoft. Não acho que forçar crenças pessoais sobre a comunidade JS não estar se movendo rápido o suficiente seja realmente benéfico.

Dizer transpile node_modules em vez de publicar um pacote que suporte tantos ambientes ativos quanto possível é um dedo médio para qualquer pessoa que dirige um negócio.

Essa não é uma atitude realmente construtiva, e não é o tipo de discurso que eu gostaria de ter no código aberto, pessoalmente.

Acho que já disse minha parte aqui. Desculpe minha decisão de melhorar a manutenção de um módulo baixado quase 60 milhões de vezes por semana não se encaixa no seu modelo de negócios.

Hoje, mais pessoas ainda usam o IE11 do que o Firefox. O IE11 ainda é compatível com a Microsoft. Não acho que forçar crenças pessoais sobre a comunidade JS não estar se movendo rápido o suficiente seja realmente benéfico.

o problema neste caso é mais que empresas que usam o ie11 massivo, depois dos meus logs 25% dos meus visitantes passam ie.

Eu gostaria de mostrar o dedo médio para, ou seja, mas quando você dirige um negócio, não pode mandá-lo para o inferno porque você quer dinheiro lá :)

Qual é a solução alternativa atual para esse problema?

Qual é a solução alternativa atual para esse problema?

2.2.0 quando você pode depois de fmoessle

Levei 3 dias para descobrir que o bug estava vindo do módulo socket.io-client lol

Eu também faço o downgrade da versão do módulo para 2.2.0 cheers all

O downgrade para 2.2.0 funcionou para mim também. Obrigado.

Talvez uma boa solução seja mudar o socket.io para este fork do debug debug-es5 que é transpilado para o es5.

Passei um dia inteiro tentando fazer com que o babel e o webpack transpilarem debug / src / browser.js e, pelos muitos tópicos em que me deparei, parece que muitas pessoas também estão se deparando com isso. Parece que há muito tempo de engenharia que pode ser economizado.

A propósito, socket.io v2.2.0 tem um vazamento de memória que foi corrigido no 'ws' v7.1.2 (https://github.com/websockets/ws/issues/1617), então tome cuidado ao fazer o downgrade.

Editar: consertou
A maioria dos posts que encontrei recomendavam parar de excluir / node_modules / do webpack, mas isso não funcionou e também é lento. (tenho certeza que o webpack estava acessando o arquivo, mas o babel não o estava transpilando, talvez relacionado a babel / preset-env)

Em vez disso, acabei de instalar debug-es5 e fiz o webpack usá-lo no lugar de debug adicionando-o ao webpack.config.js

  resolve: {
    alias: {
      debug: 'debug-es5',
    },
  },

Estou usando:

{
  test: /\.js$/,
  use: babelLoader,
  exclude: excludeNodeModulesExcept(['debug']),
},

const babelLoader = {
    loader: 'babel-loader',
    options: {
      // Don't waste time on Gzipping the cache
      cacheCompression: false,
      // This is a feature of `babel-loader` for webpack (not Babel itself).
      // It enables caching results in ./node_modules/.cache/babel-loader/
      // directory for faster rebuilds.
      cacheDirectory: true,
      plugins: ['@babel/plugin-syntax-dynamic-import'],
      presets: [['@babel/env', { modules: false }]],
      sourceMaps: includeSourcemap && !isDevelopmentMode,
    },
  };



md5-af1f69980cb7fa352eba1d2f79ce2612



const excludeNodeModulesExcept = function (modules) {
  var pathSep = path.sep;
  if (pathSep == '\\')
    // must be quoted for use in a regexp:
    pathSep = '\\\\';
  var moduleRegExps = modules.map(function (modName) {
    return new RegExp('node_modules' + pathSep + modName);
  });

  return function (modulePath) {
    if (/node_modules/.test(modulePath)) {
      for (var i = 0; i < moduleRegExps.length; i++)
        if (moduleRegExps[i].test(modulePath)) return false;
      return true;
    }
    return false;
  };
};

alterar socket.io-client para 2.2.0 funciona para mim, mas somente depois de construir e iniciar o aplicativo.

no modo dev, ainda recebo o erro

TypeError: o objeto não oferece suporte à propriedade ou método 'cbrt'
{
[funções]: ,
__proto__: {},
descrição: "Objeto não suporta propriedade ou método 'cbrt'",
mensagem: "Objeto não suporta propriedade ou método 'cbrt'",
nome: "TypeError",
número: -2146827850,
pilha: "TypeError: Objeto não suporta propriedade ou método 'cbrt'
em cielabForwardTransform (código de avaliação: 39754: 3)
em fromXYZ (código de avaliação: 39763: 3)
em claro (código de avaliação: 39706: 3)
em genVariations (código de avaliação: 39696: 5)
na análise (código de avaliação: 39606: 7)
em parsedTheme.get (código eval: 39498: 7)
em generatedStyles.get (código eval: 39466: 7)
em Theme.prototype.applyTheme (código de avaliação: 39297: 5)
at handler (código de avaliação: 39449: 13)
em Vue.prototype. $ watch (eval code: 4941: 9) ",
Símbolo (Lang fallback) _i.t81c9tw05xo: indefinido,
Símbolo (react.element) _h.t81c9tw05xo: indefinido,
Símbolo (parar) _n.t81c9tw05xo: indefinido
}

Talvez uma boa solução seja mudar o socket.io para este fork do debug debug-es5 que é transpilado para o es5.

Passei um dia inteiro tentando fazer com que o babel e o webpack transpilarem debug / src / browser.js e, pelos muitos tópicos em que me deparei, parece que muitas pessoas também estão se deparando com isso. Parece que há muito tempo de engenharia que pode ser economizado.

A propósito, socket.io v2.2.0 tem um vazamento de memória que foi corrigido no 'ws' v7.1.2 ( websockets / ws # 1617 ), então

Editar: consertou
A maioria dos posts que encontrei recomendavam parar de excluir / node_modules / do webpack, mas isso não funcionou e também é lento. (tenho certeza que o webpack estava acessando o arquivo, mas o babel não o estava transpilando, talvez relacionado a babel / preset-env)

Em vez disso, acabei de instalar debug-es5 e fiz o webpack usá-lo no lugar de debug adicionando-o ao webpack.config.js

  resolve: {
    alias: {
      debug: 'debug-es5',
    },
  },

Isso me economizou horas de trabalho - obrigado!

Eu criei um repositório muito pequeno com esse problema resolvido com a configuração básica do Webpack: https://github.com/kmaraz/debug-to-es5

A dependência debug foi revertida para 3.1.0 , que não precisa ser transpilada. Lançado em 2.3.1 .

Observe que você também pode usar o plug- in