Socket.io-client: Échec du chargement du fichier dans IE

Idem ici sur v2.3.0 et IE 11

Idem ici sur v2.3.0 et IE 11

Nous sommes revenus à 2.2.0 et il se réveille bien.

Je suis également revenu à 2.2.0 et cela fonctionne très bien. On dirait que le code exporté par le module n'est pas valide ES5.

Eh bien, ça aurait dû être transpilé par babel... Je vais y jeter un œil.

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

Je suis également revenu à 2.2.0 et cela fonctionne très bien.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/socketio/socket.io-client/issues/1328?email_source=notifications&email_token=ADDNSFI5LWY4MJXY24WZNNLQLR333A5CNFSM4I2MYYBKYY3PNVWWK3TUL52HS4DFVREXG43VMQIVJW63LNMVU8
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADDNSFNC7OUW4Z3BEWLSNRLQLR333ANCNFSM4I2MYYBA
.

Cela s'est produit après la mise à jour du débogage de la v3 à la v4 qui utilise l'opérateur de propagation dans son distribuable.
Très souvent, les node_modules sont exclus de la compilation babel pour des raisons de performances.

Je l'ai également dans 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)"

Lignes affectées

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

Je n'ai pas vraiment grand chose à ajouter car il a été identifié comme du code non transpilé.

Idem ici sur v2.3.0 et IE 11

et iOS9 Safari

Il s'agit d'un changement décisif sur une version intermédiaire que nous avons également mis à jour automatiquement. Pour ceux qui supportent encore IE11, c'est assez sérieux, il nous a fallu quelques jours pour nous en rendre compte.

Combien de temps pensez-vous qu'il leur faudra pour résoudre le problème ?

ce problème est lié à debug:4.1.0 Ils ont déjà remplacé la méthode mais il n'y a pas de nouvelle version où ce problème est résolu.

le correctif pour socket.io-client et engine.io-client serait de remplacer la version actuelle debug par la version 4.0.1 .

Malheureusement, il semble que le responsable de debug ne soit pas du tout disposé à entendre notre problème : https://github.com/visionmedia/debug/issues/668#issuecomment -576262641

Salut @darrachequesne :)

Pouvez-vous épingler le forfait debug pour socket.io-client à 4.0.1 ? Merci!

En attendant, j'ai essayé d'approcher le mainteneur de debug et lui ai demandé de reconsidérer son choix de ne plus transpiler le paquet en code ES5 : https://github.com/ visionmedia/debug/issues/745

J'ai entendu le problème des milliers de fois. Je l'ai entendu depuis que le problème a été créé pour la première fois. Veuillez transpiler votre application si vous souhaitez qu'elle fonctionne sur des navigateurs archaïques ; debug n'est que la première des nombreuses dépendances que vous rencontrerez et qui sont écrites et publiées en tant que modules ES6.

Très souvent, les node_modules sont exclus de la compilation babel pour des raisons de performances.

Cela ne signifie pas que les mainteneurs de paquets doivent garder leur code épinglé à l'âge de pierre. L'écosystème javascript est lent, oui, mais il est encore plus lent lorsque, par exemple, IE11 nous retient. La raison pour laquelle debug est souvent choisi est qu'il fait partie des 10 packages les plus dépendants et qu'il est donc généralement l'un des premiers packages à rencontrer des erreurs ou des problèmes, même si des centaines d'autres dépendances vous ralentiront. vers le bas aussi.

Si vous ne me croyez pas, transpilez manuellement debug dans votre node_modules et essayez à nouveau de regrouper votre application. Très probablement, selon la taille de votre application, le processus de regroupement échouera ailleurs.

Si vous avez un problème avec l'efficacité de Babel, ouvrez un numéro chez Babel. Si vous avez un problème avec CRA qui n'effectue pas une transpilation correcte, ouvrez un problème avec CRA.

Je ne veux pas paraître dédaigneux ; ce n'est tout simplement pas le problème de debug .

D'après ce qu'ils disent dans ce lien ici . Cela semble être un problème de configuration babel, peut-être que si le personnel modifie la configuration à l'intérieur du socket-io-client, cela peut résoudre le problème.

Correct; c'est la réponse officielle de l'équipe Babel. Veuillez y apporter vos problèmes.

Quelle réponse officielle ? Le problème lié concernait le fait que babel ne transpilait pas les packages sélectionnés à partir de node_modules lorsqu'il était configuré, et c'est corrigé.

Socket.io-client n'utilise même pas babel pour transpiler. Il utilise uniquement webpack pour regrouper toutes les dépendances dans un seul distribuable.

Alors maintenant, si socket.io-client doit être pris en charge dans les navigateurs plus anciens, il a besoin soit d'une étape de transpilation lors de la construction, soit d'une rétrogradation ou d'un remplacement de débogage.

La publication de packages pour le Web nécessitant une transpilation n'est en fait pas si courante. Au cours des années de transpilation, je ne l'ai rencontré que quelques fois, même sur des projets avec littéralement des Go de dépendances dans node_modules. Jusqu'à présent, chaque mainteneur était assez gentil pour le traiter comme un bogue...

Voici la réponse dont je parlais :

Je suis d'accord que ce n'est pas un bug debug , mais un problème avec la façon dont Babel a été configuré.

Si vous configurez Babel pour transpiler les modules de nœuds mais que cela ne fonctionne toujours pas, veuillez fournir un référentiel minimal que je peux cloner pour enquêter.

Alors maintenant, si socket.io-client doit être pris en charge dans les anciens navigateurs, il a besoin de . . . une étape de transpilation

Correct. C'est l'état du développement Web moderne.

avec littéralement des Go de dépendances dans node_modules

C'est le vrai problème. Pas debug choisissant de ne pas transpiler. En utilisant les modules ES6, ce n'est généralement pas un problème car votre application ne regroupera que les dépendances qu'elle utilise et ne transpilera donc que les dépendances qu'elle utilise. Les gens font cela à bon escient tous les jours.

Jusqu'à présent, chaque mainteneur était assez gentil pour le traiter comme un bogue...

L'utilisation de versions parfaitement valides de Javascript n'est pas un bug.

Dire transpiler node_modules au lieu de publier un package qui prend en charge autant d'environnements actifs que possible est un doigt d'honneur pour quiconque dirige une entreprise.
Je dois sélectionner soigneusement chaque package à transpiler, car tout transpiler depuis node_modules plus que quadrupler le temps de construction de certains projets - parfois de plusieurs minutes à une heure. Personne n'a le temps pour ça.
Aujourd'hui, plus de gens utilisent encore IE11 que Firefox. IE11 est toujours pris en charge par Microsoft. Je ne pense pas que forcer les croyances personnelles sur le fait que la communauté JS n'avance pas assez vite soit vraiment utile.

Dire transpiler node_modules au lieu de publier un package qui prend en charge autant d'environnements actifs que possible est un doigt d'honneur pour quiconque dirige une entreprise.

Ce n'est pas vraiment une attitude constructive, et pas le genre de discours que j'aimerais avoir en open source, personnellement.

Je pense que j'ai dit mon morceau ici. Désolé, ma décision d'améliorer la maintenabilité d'un module téléchargé près de 60 millions de fois par semaine ne correspond pas à votre modèle économique.

Aujourd'hui, plus de gens utilisent encore IE11 que Firefox. IE11 est toujours pris en charge par Microsoft. Je ne pense pas que forcer les croyances personnelles sur le fait que la communauté JS n'avance pas assez vite soit vraiment utile.

le problème dans ce cas est plus que les entreprises utilisant ie11 massive, après mes journaux, 25% de mes visiteurs viennent par exemple.

Je voudrais montrer le majeur à ie, mais quand vous dirigez une entreprise, vous ne pouvez pas les envoyer en enfer parce que vous voulez de l'argent :)

Quelle est la solution de contournement actuelle pour ce problème ?

Quelle est la solution de contournement actuelle pour ce problème ?

2.2.0 quand tu peux après fmoessle

Il m'a fallu 3 jours pour découvrir que le bug venait du module socket.io-client lol

Moi aussi je rétrograde la version du module à 2.2.0 bravo à tous

La mise à niveau vers la version 2.2.0 a également fonctionné pour moi. Merci.

Peut-être qu'une bonne solution consiste à basculer socket.io vers ce fork de débogage debug-es5 qui est transpilé en es5.

J'ai passé une journée entière à essayer de faire en sorte que babel et webpack transpilent debug/src/browser.js et d'après les nombreux fils de discussion sur lesquels je suis tombé, il semble que beaucoup de gens se heurtent également à cela. On dirait que beaucoup de temps d'ingénierie pourrait être économisé.

Soit dit en passant, socket.io v2.2.0 a une fuite de mémoire qui a été corrigée dans 'ws' v7.1.2 (https://github.com/websockets/ws/issues/1617), alors faites attention à la rétrogradation.

Edit : c'est corrigé
La plupart des messages que j'ai trouvés recommandaient d'arrêter d'exclure /node_modules/ de webpack, mais cela n'a pas fonctionné et est également lent. (à peu près sûr que webpack frappait le fichier mais babel ne le transpilait pas, peut-être lié à babel/preset-env)

Au lieu de cela, je viens d'installer debug-es5 et j'ai utilisé webpack à la place de debug en l'ajoutant au webpack.config.js

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

J'utilise:

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

changer socket.io-client en 2.2.0 fonctionne pour moi, mais seulement après la construction et le démarrage de l'application.

en mode dev, j'ai toujours l'erreur

TypeError : l'objet ne prend pas en charge la propriété ou la méthode 'cbrt'
{
[les fonctions]: ,
__proto__ : { },
description: "L'objet ne prend pas en charge la propriété ou la méthode 'cbrt'",
message : "L'objet ne prend pas en charge la propriété ou la méthode 'cbrt'",
nom : "TypeError",
numéro : -2146827850,
stack : "TypeError : l'objet ne prend pas en charge la propriété ou la méthode 'cbrt'
à cielabForwardTransform (code eval:39754:3)
à partir de XYZ (code eval:39763:3)
à alléger (code eval:39706:3)
à genVariations (code eval:39696:5)
à l'analyse (code eval:39606:7)
à parsedTheme.get (code eval:39498:7)
sur generateStyles.get (code eval:39466:7)
à Theme.prototype.applyTheme (code eval:39297:5)
au gestionnaire (code eval:39449:13)
à Vue.prototype.$watch (code eval:4941:9)",
Symbol(Lang fallback)_i.t81c9tw05xo : non défini,
Symbol(react.element)_h.t81c9tw05xo : non défini,
Symbole(stop)_n.t81c9tw05xo : non défini
}

Peut-être qu'une bonne solution consiste à basculer socket.io vers ce fork de débogage debug-es5 qui est transpilé en es5.

J'ai passé une journée entière à essayer de faire en sorte que babel et webpack transpilent debug/src/browser.js et d'après les nombreux fils de discussion sur lesquels je suis tombé, il semble que beaucoup de gens se heurtent également à cela. On dirait que beaucoup de temps d'ingénierie pourrait être économisé.

Soit dit en passant, socket.io v2.2.0 a une fuite de mémoire qui a été corrigée dans 'ws' v7.1.2 ( websockets/ws#1617 ) alors soyez prudent lors de la rétrogradation.

Edit : c'est corrigé
La plupart des messages que j'ai trouvés recommandaient d'arrêter d'exclure /node_modules/ de webpack, mais cela n'a pas fonctionné et est également lent. (à peu près sûr que webpack frappait le fichier mais babel ne le transpilait pas, peut-être lié à babel/preset-env)

Au lieu de cela, je viens d'installer debug-es5 et j'ai utilisé webpack à la place de debug en l'ajoutant au webpack.config.js

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

Cela m'a permis d'économiser des heures de travail - merci !

J'ai créé un très petit dépôt avec ce problème résolu avec la configuration de base de Webpack : https://github.com/kmaraz/debug-to-es5

La dépendance debug été ramenée à 3.1.0 , qui n'a pas besoin d'être transpilée. Publié en 2.3.1 .

Veuillez noter que vous pouvez également utiliser le plugin webpack-remove-debug , afin de supprimer tout appel à la dépendance de débogage (jusqu'à ce que nous trouvions un moyen approprié de fournir une version avec et sans débogage).