Socket.io-client: Fehler beim Laden der Datei in IE

Dasselbe hier bei v2.3.0 und IE 11

Dasselbe hier bei v2.3.0 und IE 11

Wir sind auf 2.2.0 zurückgekehrt und es funktioniert einwandfrei.

Ich habe auch auf 2.2.0 zurückgesetzt und es funktioniert gut. Scheint, als ob der vom Modul exportierte Code kein gültiger ES5 ist.

Nun, es sollte von Babel übertragen worden sein... Ich werde mir das ansehen.

Le jeu. 26. September 2019 à 11:09, orangejuice [email protected] a
schreiben:

Ich habe auch auf 2.2.0 zurückgesetzt und es funktioniert gut.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/socketio/socket.io-client/issues/1328?email_source=notifications&email_token=ADDNSFI5LWY4MJXY24WZNNLQLR333A5CNFSM4I2MYYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LDN13
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ADDNSFNC7OUW4Z3BEWLSNRLQLR333ANCNFSM4I2MYYBA
.

Dies geschah nach der Aktualisierung des Debug von v3 auf v4, das den Spread-Operator in seiner verteilbaren Datei verwendet.
Sehr oft werden node_modules aus Performancegründen von der Babel-Kompilierung ausgeschlossen.

Habe das auch im 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)"

Betroffene Leitungen

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

Ich habe nicht viel hinzuzufügen, da es als nicht transpilierter Code identifiziert wurde.

Dasselbe hier bei v2.3.0 und IE 11

und iOS9 Safari

Dies ist eine bahnbrechende Änderung an einem Point-Release, das auch automatisch aktualisiert wurde. Für diejenigen, die immer noch IE11 unterstützen, ist dies ziemlich ernst, wir haben einige Tage gebraucht, um es zu erkennen.

Wie lange werden Sie voraussichtlich brauchen, um das Problem zu beheben?

Dieses Problem bezieht sich auf debug:4.1.0 Sie haben die Methode bereits ersetzt, aber es gibt keine neue Version, bei der dieses Problem behoben ist.

Fix für socket.io-client und engine.io-client wäre, die aktuelle Version debug durch die Version 4.0.1 zu ersetzen.

Leider scheint es so, als ob der Betreuer von debug unser Problem überhaupt nicht hören möchte: https://github.com/visionmedia/debug/issues/668#issuecomment -576262641

Hallo @darrachequesne :)

Können Sie bitte das Paket debug für socket.io-client an 4.0.1 anheften? Dankeschön!

In der Zwischenzeit habe ich versucht, den Betreuer von debug zu kontaktieren und ihn gebeten, seine Entscheidung, das Paket nicht mehr in ES5 Code zu transpilieren, zu überdenken: https://github.com/ visionmedia/debug/probleme/745

Ich habe das Problem tausendmal gehört. Ich habe es gehört, seit das Problem zum ersten Mal erstellt wurde. Bitte transpilieren Sie Ihre Anwendung, wenn sie in archaischen Browsern funktionieren soll; debug ist nur die erste von vielen Abhängigkeiten, die als ES6-Module geschrieben und veröffentlicht werden.

Sehr oft werden node_modules aus Performancegründen von der Babel-Kompilierung ausgeschlossen.

Dies bedeutet nicht, dass Paketbetreuer ihren Code an die Steinzeit binden sollten. Das Javascript-Ökosystem ist langsam, ja, aber es ist noch langsamer, wenn uns zB IE11 zurückhält. Der Grund, warum debug wird, ist, dass es eines der 10 am stärksten abhängigen Pakete ist und daher normalerweise eines der ersten Pakete ist, bei denen Fehler oder Probleme auftreten, auch wenn Hunderte anderer Abhängigkeiten Sie verlangsamen werden auch runter.

Wenn Sie mir nicht glauben, transpilieren Sie debug manuell in Ihr node_modules und versuchen Sie erneut, Ihre App zu bündeln. Abhängig von der Größe Ihrer Anwendung wird der Bündelungsprozess höchstwahrscheinlich an anderer Stelle fehlschlagen.

Wenn Sie ein Problem mit der Effizienz von Babel haben, eröffnen Sie ein Problem bei Babel. Wenn Sie ein Problem damit haben, dass CRA keine ordnungsgemäße Transpilation durchführt, öffnen Sie ein Problem mit CRA.

Ich möchte nicht abweisend wirken; das ist einfach nicht das Problem von debug .

Von dem, was sie in diesem Link hier sagen. Es scheint ein Konfigurationsproblem von Babel zu sein, vielleicht kann es das Problem lösen, wenn das Personal die Konfiguration im socket-io-client ändert.

Richtig; das ist die offizielle Antwort des Babel-Teams. Bitte nehmen Sie Ihre Probleme dort auf.

Welche offizielle Antwort? Das verknüpfte Problem betraf, dass Babel ausgewählte Pakete von node_modules nicht transpilierte, wenn es so konfiguriert wurde, und es ist behoben.

Der Socket.io-Client verwendet nicht einmal Babel zum Transpilieren. Es verwendet nur Webpack, um alle Abhängigkeiten in einem einzigen verteilbaren Paket zu bündeln.

Wenn socket.io-client nun in älteren Browsern unterstützt werden soll, benötigt es entweder einen Transpilationsschritt während des Erstellens oder es muss ein Downgrade oder Debug ersetzen.

Das Veröffentlichen von Paketen für das Web, die eine Transpilation benötigen, ist eigentlich nicht so üblich. Im Laufe der Jahre des Transpilierens bin ich darauf nur ein paar Mal gestoßen, selbst bei Projekten mit buchstäblich GBs an Abhängigkeiten in node_modules. Bisher war jeder Betreuer so nett, es als Bug zu behandeln...

Dies ist die Antwort, auf die ich mich bezog:

Ich stimme zu, dass dies kein debug Fehler ist, sondern ein Problem mit der Konfiguration von Babel.

Wenn Sie Babel so konfigurieren, dass es Knotenmodule transpiliert, es aber immer noch nicht funktioniert, stellen Sie bitte ein minimales Repository bereit, das ich klonen kann, um es zu untersuchen.

Wenn also socket.io-client in älteren Browsern unterstützt werden soll, braucht es . . . ein Transpilationsschritt

Richtig. Das ist der Stand der modernen Webentwicklung.

mit buchstäblich GBs Abhängigkeiten in node_modules

Dies ist das eigentliche Problem. Nicht debug , die nicht transpilieren. Bei der Verwendung von ES6-Modulen ist dies im Allgemeinen kein Problem, da Ihre Anwendung nur die von ihr verwendeten Abhängigkeiten bündelt und somit nur die von ihr verwendeten Abhängigkeiten transpiliert. Die Menschen tun dies jeden Tag mit großer Wirkung.

Bisher war jeder Betreuer so nett, es als Bug zu behandeln...

Die Verwendung absolut gültiger Javascript-Versionen ist kein Fehler.

Zu sagen, transpile node_modules statt ein Paket zu veröffentlichen, das so viele aktive Umgebungen wie möglich unterstützt, ist für jeden, der ein Unternehmen betreibt, ein Mittelfinger.
Ich muss jedes zu transpilierende Paket sorgfältig auswählen, da das Transpilieren von node_modules die Build-Zeit einiger Projekte mehr als vervierfacht - manchmal von mehreren Minuten bis zu einer Stunde. Dafür hat niemand Zeit.
Heute verwenden immer noch mehr Leute IE11 als Firefox. IE11 wird weiterhin von Microsoft unterstützt. Ich glaube nicht, dass es wirklich gut ist, persönliche Überzeugungen darüber zu erzwingen, dass sich die JS-Community nicht schnell genug bewegt.

Zu sagen, transpile node_modules statt ein Paket zu veröffentlichen, das so viele aktive Umgebungen wie möglich unterstützt, ist für jeden, der ein Unternehmen betreibt, ein Mittelfinger.

Das ist nicht wirklich eine konstruktive Haltung und nicht die Art von Diskurs, die ich persönlich gerne in Open Source führen würde.

Ich glaube, ich habe mein Stück hier gesagt. Es tut mir leid, dass meine Entscheidung, die Wartbarkeit eines Moduls, das fast 60 Millionen Mal pro Woche heruntergeladen wurde, zu verbessern, nicht zu Ihrem Geschäftsmodell passt.

Heute verwenden immer noch mehr Leute IE11 als Firefox. IE11 wird weiterhin von Microsoft unterstützt. Ich glaube nicht, dass es wirklich gut ist, persönliche Überzeugungen darüber zu erzwingen, dass sich die JS-Community nicht schnell genug bewegt.

Das Problem in diesem Fall ist mehr als die Unternehmen, die ie11 massiv verwenden, nach meinen Protokollen kommen 25% meiner Besucher durch ie.

Ich würde gerne den Mittelfinger zeigen, aber wenn du ein Geschäft führst, kannst du sie nicht in die Hölle schicken, weil du dort Geld willst :)

Was ist die aktuelle Problemumgehung für dieses Problem?

Was ist die aktuelle Problemumgehung für dieses Problem?

2.2.0 wenn du kannst nach fmoessle

Ich habe 3 Tage gebraucht, um herauszufinden, dass der Fehler vom socket.io-client Modul kommt lol

Ich habe auch ein Downgrade der Modulversion auf 2.2.0 gemacht

Ein Downgrade auf 2.2.0 hat bei mir auch funktioniert. Vielen Dank.

Vielleicht ist es eine gute Lösung, socket.io auf diese Abzweigung von debug debug-es5 umzustellen , die auf es5 transpiliert wird.

Ich habe einen ganzen Tag damit verbracht, Babel und Webpack dazu zu bringen, debug/src/browser.js zu transpilieren, und aus den vielen Threads, über die ich gestolpert bin, scheint es, als würden auch viele Leute darauf stoßen. Es scheint, als könnte viel Engineering-Zeit eingespart werden.

Übrigens hat socket.io v2.2.0 ein Speicherleck, das in 'ws' v7.1.2 (https://github.com/websockets/ws/issues/1617) behoben wurde, also sei vorsichtig beim Downgrade.

Edit: habe es behoben
Die meisten Beiträge, die ich gefunden habe, empfahlen, /node_modules/ nicht mehr vom Webpack auszuschließen, aber das hat nicht funktioniert und ist auch langsam. (ziemlich sicher, dass das Webpack die Datei traf, aber Babel hat sie nicht transpiliert, vielleicht im Zusammenhang mit babel/preset-env)

Stattdessen habe ich einfach debug-es5 installiert und webpack dies anstelle von debug indem ich dies zur webpack.config.js hinzugefügt habe

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

Ich benutze:

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

Die Änderung von socket.io-client auf 2.2.0 funktioniert bei mir, aber erst nach dem Erstellen und Starten der Anwendung.

Im Dev-Modus bekomme ich immer noch den Fehler

TypeError: Objekt unterstützt keine Eigenschaft oder Methode 'cbrt'
{
[Funktionen]: ,
__proto__: { },
Beschreibung: "Objekt unterstützt keine Eigenschaft oder Methode 'cbrt'",
Meldung: "Objekt unterstützt die Eigenschaft oder Methode 'cbrt' nicht",
Name: "TypeError",
Nummer: -2146827850,
stack: "TypeError: Objekt unterstützt nicht die Eigenschaft oder Methode 'cbrt'
bei cielabForwardTransform (Evaluierungscode:39754:3)
bei fromXYZ (Auswertungscode:39763:3)
bei Aufhellung (Evalcode:39706:3)
bei genVariationen (Evalcode:39696:5)
beim Parsen (Auswertungscode:39606:7)
bei parsedTheme.get (Evaluierungscode:39498:7)
bei generiertStyles.get (eval code:39466:7)
unter Theme.prototype.applyTheme (Evaluierungscode:39297:5)
beim Handler (Auswertungscode:39449:13)
bei Vue.prototype.$watch (Evaluierungscode:4941:9)",
Symbol(Lang Fallback)_i.t81c9tw05xo: undefiniert,
Symbol(react.element)_h.t81c9tw05xo: undefiniert,
Symbol(Halt)_n.t81c9tw05xo: undefiniert
}

Vielleicht ist es eine gute Lösung, socket.io auf diese Abzweigung von debug debug-es5 umzustellen , die auf es5 transpiliert wird.

Ich habe einen ganzen Tag damit verbracht, Babel und Webpack dazu zu bringen, debug/src/browser.js zu transpilieren, und aus den vielen Threads, über die ich gestolpert bin, scheint es, als würden auch viele Leute darauf stoßen. Es scheint, als könnte viel Engineering-Zeit eingespart werden.

Übrigens hat socket.io v2.2.0 ein Speicherleck, das in 'ws' v7.1.2 ( websockets/ws#1617 )

Edit: habe es behoben
Die meisten Beiträge, die ich gefunden habe, empfahlen, /node_modules/ nicht mehr vom Webpack auszuschließen, aber das hat nicht funktioniert und ist auch langsam. (ziemlich sicher, dass das Webpack die Datei traf, aber Babel hat sie nicht transpiliert, vielleicht im Zusammenhang mit babel/preset-env)

Stattdessen habe ich einfach debug-es5 installiert und webpack dies anstelle von debug indem ich dies zur webpack.config.js hinzugefügt habe

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

Das hat mir stundenlange Arbeit gespart - danke!

Ich habe ein sehr kleines Repo erstellt, bei dem dieses Problem mit der grundlegenden Webpack-Konfiguration gelöst wurde: https://github.com/kmaraz/debug-to-es5

Die Abhängigkeit von debug wurde auf 3.1.0 , die nicht transpiliert werden muss. Veröffentlicht in 2.3.1 .

Bitte beachten Sie, dass Sie auch das webpack-remove-debug- Plugin verwenden können, um jeden Aufruf der Debug-Abhängigkeit zu entfernen (bis wir einen geeigneten Weg gefunden haben, einen Build mit und ohne Debug bereitzustellen).