Socket.io-client: No poder cargar el archivo en IE

Lo mismo aquí en v2.3.0 e IE 11

Lo mismo aquí en v2.3.0 e IE 11

Volvimos a la 2.2.0 y está funcionando bien.

También volví a 2.2.0 y funciona bien. Parece que el código exportado por el módulo no es ES5 válido.

Bueno, debería haber sido transpilado por Babel ... Voy a echar un vistazo a esto.

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

También volví a 2.2.0 y funciona bien.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/socketio/socket .
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADDNSFNC7OUW4Z3BEWLSNRLQLR333ANCNFSM4I2MYYBA
.

Esto sucedió después de actualizar debug de v3 a v4 que usa el operador de propagación en su distributable.
Muy a menudo, los node_modules se excluyen de la compilación de babel por razones de rendimiento.

También tengo esto en 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)"

Líneas afectadas

/**
 * 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);
}

Realmente no tengo mucho que agregar, ya que se ha identificado como código no transpilado.

Lo mismo aquí en v2.3.0 e IE 11

y Safari iOS9

Este es un cambio importante en una versión puntual que también actualizamos automáticamente. Para aquellos que todavía apoyan IE11, esto es bastante serio, nos tomó unos días darnos cuenta.

¿Cuánto tiempo espera que tarden en solucionar el problema?

este problema está relacionado con debug:4.1.0 Ya han reemplazado el método, pero aún no hay una nueva compilación donde se solucione este problema.

corregir para socket.io-client y engine.io-client sería reemplazar la versión actual debug con la versión 4.0.1 .

Desafortunadamente, parece que el mantenedor de debug no está dispuesto a escuchar nuestro problema en absoluto: https://github.com/visionmedia/debug/issues/668#issuecomment -576262641

Hola @darrachequesne :)

¿Puedes fijar el paquete debug por socket.io-client a 4.0.1 ? ¡Gracias!

Mientras tanto, traté de acercarme al mantenedor de debug y le pedí que reconsiderara su elección de no transpilar el paquete al código ES5 más: https://github.com/ visionmedia / debug / issues / 745

He escuchado el problema miles de veces. Lo he escuchado desde que se creó el problema. Transpile tu aplicación si quieres que funcione en navegadores arcaicos; debug es solo la primera de muchas dependencias con las que se encontrará que están escritas y publicadas como módulos ES6.

Muy a menudo, los node_modules se excluyen de la compilación de babel por razones de rendimiento.

Esto no significa que los mantenedores de paquetes deban mantener su código fijado a la edad de piedra. El ecosistema de javascript es lento, sí, pero es aún más lento cuando, por ejemplo, IE11 nos retiene. La razón por la que se elige mucho debug es porque es uno de los 10 paquetes más dependientes y, por lo tanto, suele ser uno de los primeros paquetes en encontrar errores o problemas, aunque cientos de otras dependencias lo ralentizarán. abajo también.

Si no me cree, transpile manualmente debug en su node_modules e intente agrupar su aplicación nuevamente. Lo más probable es que, según el tamaño de su aplicación, el proceso de agrupación falle en otro lugar.

Si tiene un problema con la eficiencia de Babel, abra un problema en Babel. Si tiene un problema con CRA que no realiza la transpilación adecuada, abra un problema con CRA.

No quiero parecer desdeñoso; esto simplemente no es un problema de debug .

Por lo que dicen en este enlace aquí . Parece ser un problema de configuración de babel, tal vez si el personal cambia la configuración dentro del socket-io-client , puede resolver el problema.

Correcto; esa es la respuesta oficial del equipo de Babel. Lleve sus problemas allí.

¿Qué respuesta oficial? El problema vinculado era que babel no transpilaba los paquetes seleccionados de node_modules cuando se configuraba, y se solucionó.

Socket.io-client ni siquiera usa babel para transpilar. Solo usa webpack para agrupar todas las dependencias en un solo distribuible.

Entonces, si socket.io-client va a ser compatible con navegadores más antiguos, necesita un paso de transpilación durante la compilación o debe degradar o reemplazar la depuración.

La publicación de paquetes para la web que necesitan transpilación en realidad no es tan común. A lo largo de los años de transpilación, lo encontré solo unas pocas veces, incluso en proyectos con literalmente GB de dependencias en node_modules. Hasta ahora, todos los mantenedores eran lo suficientemente amables como para tratarlo como un error ...

Esta es la respuesta a la que me refería:

Estoy de acuerdo en que esto no es un error de debug , sino un problema con la configuración de Babel.

Si configura Babel para transpilar módulos de nodo pero aún no funciona, proporcione un repositorio mínimo que pueda clonar para investigar.

Entonces, si socket.io-client va a ser compatible con navegadores más antiguos, es necesario. . . un paso de transpilación

Correcto. Ese es el estado del desarrollo web moderno.

con literalmente GB de dependencias en node_modules

Este es el verdadero problema. No debug eligiendo no transpilar. Al usar módulos ES6, esto generalmente no es un problema porque su aplicación solo agrupará las dependencias que usa y, por lo tanto, solo transpilará las dependencias que use. La gente hace esto con gran efecto todos los días.

Hasta ahora, todos los mantenedores eran lo suficientemente amables como para tratarlo como un error ...

Usar versiones perfectamente válidas de Javascript no es un error.

Decir transpile node_modules en lugar de publicar un paquete que admita tantos entornos activos como sea posible es un dedo medio para cualquiera que tenga una empresa.
Necesito seleccionar cuidadosamente cada paquete para transpilar, ya que transpilar todo, desde node_modules, cuadruplica el tiempo de construcción de algunos proyectos, a veces desde varios minutos hasta una hora. Nadie tiene tiempo para eso.
Hoy en día, más personas siguen usando IE11 que Firefox. IE11 todavía es compatible con Microsoft. No creo que forzar las creencias personales sobre que la comunidad JS no se mueve lo suficientemente rápido realmente esté haciendo algo bueno.

Decir transpile node_modules en lugar de publicar un paquete que admita tantos entornos activos como sea posible es un dedo medio para cualquiera que tenga una empresa.

Esa no es realmente una actitud constructiva, y no es el tipo de discurso que me gustaría tener en código abierto, personalmente.

Creo que he dicho mi pieza aquí. Lamento que mi decisión de mejorar la capacidad de mantenimiento de un módulo descargado casi 60 millones de veces a la semana no se ajusta a su modelo de negocio.

Hoy en día, más personas siguen usando IE11 que Firefox. IE11 todavía es compatible con Microsoft. No creo que forzar las creencias personales sobre que la comunidad JS no se mueve lo suficientemente rápido realmente esté haciendo algo bueno.

el problema en este caso es más que las empresas que utilizan ie11 masivo, después de que mis registros lleguen el 25% de mis visitantes.

Me gustaría mostrar el dedo medio a, es decir, pero cuando manejas un negocio no puedes enviarlos al infierno porque quieres dinero :)

¿Cuál es la solución alternativa actual para este problema?

¿Cuál es la solución alternativa actual para este problema?

2.2.0 cuando puedes después de fmoessle

Me tomó 3 días descubrir que el error provenía del módulo socket.io-client lol

Yo también bajé la versión del módulo a 2.2.0 salud a todos

La degradación a 2.2.0 también funcionó para mí. Gracias.

Quizás una buena solución es cambiar socket.io a esta bifurcación de debug debug-es5 que se transpila a es5.

Pasé un día entero tratando de hacer que babel y webpack transpile debug / src / browser.js y, de los muchos hilos con los que me he encontrado, parece que mucha gente también se está encontrando con esto. Parece que se podría ahorrar mucho tiempo de ingeniería.

Por cierto, socket.io v2.2.0 tiene una pérdida de memoria que se corrigió en 'ws' v7.1.2 (https://github.com/websockets/ws/issues/1617), así que tenga cuidado con la degradación.

Editar: lo arreglé
La mayoría de las publicaciones que encontré recomendaban dejar de excluir / node_modules / del paquete web, pero esto no funcionó y también es lento. (bastante seguro de que el paquete web estaba golpeando el archivo, pero babel no lo estaba transpilando, tal vez relacionado con babel / preset-env)

En su lugar, acabo de instalar debug-es5 y el paquete web lo usó en lugar de debug agregando esto al webpack.config.js

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

Estoy 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;
  };
};

cambiar socket.io-client a 2.2.0 funciona para mí, pero solo después de compilar e iniciar la aplicación.

en modo dev todavía recibo el error

TypeError: el objeto no admite la propiedad o el método 'cbrt'
{
[funciones]:,
__proto__: {},
descripción: "El objeto no admite la propiedad o el método 'cbrt'",
mensaje: "El objeto no admite la propiedad o el método 'cbrt'",
nombre: "TypeError",
número: -2146827850,
pila: "TypeError: el objeto no admite la propiedad o el método 'cbrt'
en cielabForwardTransform (código de evaluación: 39754: 3)
en fromXYZ (código de evaluación: 39763: 3)
aligerado (código de evaluación: 39706: 3)
en genVariations (código de evaluación: 39696: 5)
en parse (código de evaluación: 39606: 7)
en parsedTheme.get (código de evaluación: 39498: 7)
en generateStyles.get (código de evaluación: 39466: 7)
en Theme.prototype.applyTheme (código de evaluación: 39297: 5)
en el controlador (código de evaluación: 39449: 13)
en Vue.prototype. $ watch (código de evaluación: 4941: 9) ",
Símbolo (reserva de idioma) _i.t81c9tw05xo: indefinido,
Símbolo (elemento de reacción) _h.t81c9tw05xo: indefinido,
Símbolo (parada) _n.t81c9tw05xo: indefinido
}

Quizás una buena solución es cambiar socket.io a esta bifurcación de debug debug-es5 que se transpila a es5.

Pasé un día entero tratando de hacer que babel y webpack transpile debug / src / browser.js y, de los muchos hilos con los que me he encontrado, parece que mucha gente también se está encontrando con esto. Parece que se podría ahorrar mucho tiempo de ingeniería.

Por cierto, socket.io v2.2.0 tiene una pérdida de memoria que se corrigió en 'ws' v7.1.2 ( websockets / ws # 1617 ), así que tenga cuidado con la degradación.

Editar: lo arreglé
La mayoría de las publicaciones que encontré recomendaban dejar de excluir / node_modules / del paquete web, pero esto no funcionó y también es lento. (bastante seguro de que el paquete web estaba golpeando el archivo, pero babel no lo estaba transpilando, tal vez relacionado con babel / preset-env)

En su lugar, acabo de instalar debug-es5 y el paquete web lo usó en lugar de debug agregando esto al webpack.config.js

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

Esto me ahorró horas de trabajo, ¡gracias!

He creado un repositorio muy pequeño con este problema resuelto con la configuración básica de Webpack: https://github.com/kmaraz/debug-to-es5

La dependencia debug se revirtió a 3.1.0 , que no necesita transpilarse. Publicado en 2.3.1 .

Tenga en cuenta que también puede usar el complemento webpack-remove-debug para eliminar cualquier llamada a la dependencia de depuración (hasta que encontremos una forma adecuada de proporcionar una compilación con y sin depuración).