Socket.io-client: Failing to load the file in IE

Same here on v2.3.0 and IE 11

Same here on v2.3.0 and IE 11

We reverted back to 2.2.0 and it is woking fine.

I also reverted to 2.2.0 and it works fine. Seems like the code exported by the module is not valid ES5.

Well, it shoud have been transpiled by babel... I'll take a look at this.

Le jeu. 26 sept. 2019 à 11:09, orangejuice notifications@github.com a
écrit :

I also reverted to 2.2.0 and it works fine.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/socketio/socket.io-client/issues/1328?email_source=notifications&email_token=ADDNSFI5LWY4MJXY24WZNNLQLR333A5CNFSM4I2MYYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7U4IVQ#issuecomment-535413846,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADDNSFNC7OUW4Z3BEWLSNRLQLR333ANCNFSM4I2MYYBA
.

This happened after updating debug from v3 to v4 which uses spread operator in its distributable.
Very often node_modules are excluded from babel compilation for performance reasons.

Got this in IE11 as well.

"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)"

Affected lines

/**
 * Invokes `console.log()` when available.
 * No-op when `console.log` is not a "function".
 *
 * @api 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);
}

Don't really have much to add as it's been identified as non transpiled code.

Same here on v2.3.0 and IE 11

and iOS9 Safari

This is a breaking change on a point release that we got automatically upgraded too. For those who still support IE11 this is quite serious, took us a few days to realise.

How long do you expect to take them to fix the issue?

this issue is related to debug:4.1.0 They have already replaced the method but sill no new build where this issue is fixed.

fix for socket.io-client and engine.io-client would be to replace the current version debug with version 4.0.1.

Unfortunately, it seems like the maintainer of debug is not willing to hear our problem at all: https://github.com/visionmedia/debug/issues/668#issuecomment-576262641

Hi @darrachequesne :)

Can you please pin the debug package for socket.io-client to 4.0.1? Thank you!

In the mean time I tried to approach the maintainer of debug and asked him to please re-consider his choice not to transpile the package to ES5 code anymore: https://github.com/visionmedia/debug/issues/745

I've heard the problem a thousand times. I've heard it since the problem was first created. Please transpile your application if you want it to work on archaic browsers; debug is just the first of many dependencies you'll run into that are written and published as ES6 modules.

Very often node_modules are excluded from babel compilation for performance reasons.

This doesn't mean package maintainers should keep their code pinned to the stone ages. The javascript ecosystem is slow, yes, but it's even slower when e.g. IE11 keeps us held back. The reason why debug is picked on a lot is because it's one of the top 10 most depended upon packages and thus is usually one of the first packages to encounter errors or issues, even though 100's of other dependencies will slow you down, too.

If you don't believe me, manually transpile debug in your node_modules and try to bundle your app again. Most likely, depending on the size of your application, the bundling process will fail elsewhere.

If you have a problem with Babel's efficiency, open an issue at Babel. If you have a problem with CRA not performing proper transpilation, open an issue with CRA.

I don't want to come off as dismissive; this just isn't debug's problem.

From what they say in this link here. It seems to be a babel configuration problem, maybe if the staff changes the configuration inside the socket-io-client it can solve the problem.

Correct; that is the official response from the Babel team. Please take your issues there.

What official response? Linked issue was about babel not transpiling selected packages from node_modules when configured to, and it's fixed.

Socket.io-client doesn't even use babel for transpiling. It only uses webpack to bundle all dependencies into a single distributable.

So now, if socket.io-client is to be supported in older browsers it needs either a transpilation step while building or it needs to downgrade or replace debug.

Publishing packages for web that need transpilation is actually not that common. Over the years of transpiling i encountered it only a few times even on projects with literally GBs of dependencies in node_modules. Until now every maintainer was nice enough to treat it as a bug...

This is the response I was referring to:

I agree that this is not a debug bug, but a problem with how Babel has been configured.

If you configure Babel to transpile node modules but it still isn't working, please provide a minimal repository I can clone to investigate.

So now, if socket.io-client is to be supported in older browsers it needs . . . a transpilation step

Correct. That is the state of modern web development.

with literally GBs of dependencies in node_modules

This is the real problem. Not debug choosing not to transpile. By using ES6 modules, this is generally not an issue because your application will only bundle the dependencies it uses, and thus will only transpile the dependencies it uses. People do this to great effect every day.

Until now every maintainer was nice enough to treat it as a bug...

Using perfectly valid versions of Javascript is not a bug.

Saying transpile node_modules instead of publishing a package that supports as many active environments as possible is such a middle finger to anyone running a business.
I need to carefully select each package to transpile since transpiling everything from node_modules more than quadruples build time of some projects - sometimes from several minutes to an hour. Nobody has time for that.
Today more people are still using IE11 than Firefox. IE11 is still supported by Microsoft. I don't think that forcing personal beliefs about JS community not moving fast enough is really doing any good.

Saying transpile node_modules instead of publishing a package that supports as many active environments as possible is such a middle finger to anyone running a business.

That's not really a constructive attitude, and not the kind of discourse I'd like to have in open source, personally.

I think I've said my piece here. Sorry my decision to improve the maintainability of a module downloaded nearly 60 million times a week doesn't fit your business model.

Today more people are still using IE11 than Firefox. IE11 is still supported by Microsoft. I don't think that forcing personal beliefs about JS community not moving fast enough is really doing any good.

the problem in this case is more thaht companies using ie11 massive, after my logs 25% of my visitors come by ie.

I would like to show the middle finger to ie but when u run a business u cant send them to hell because u want there money :)

What is the current workaround for this issue?

What is the current workaround for this issue?

2.2.0 when u can after fmoessle

Took me 3 days to find out the bug was coming from socket.io-client module lol

Me too I downgrade module version to 2.2.0 cheers all

Downgrading to 2.2.0 worked for me as well. Thanks.

Maybe a good solution is to switch socket.io to this fork of debug debug-es5 that is transpiled to es5.

I've spent an entire day trying to get babel and webpack to transpile debug/src/browser.js and from the many threads I've stumbled on it seems like a lot of people are running into this too. Seems like a lot of engineering time that could be saved.

By the way, socket.io v2.2.0 has a memory leak that was fixed in 'ws' v7.1.2 (https://github.com/websockets/ws/issues/1617) so be careful downgrading.

Edit: got it fixed
Most posts I found were recommending to stop excluding /node_modules/ from webpack but this didn't work and also is slow. (pretty sure webpack was hitting the file but babel wasn't transpiling it, maybe related to babel/preset-env)

Instead, I just installed debug-es5 and had webpack use that in place of debug by adding this to the webpack.config.js

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

I am using:

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

changing socket.io-client to 2.2.0 works for me but only after building and starting the application.

in dev mode I still get the error

TypeError: Object doesn't support property or method 'cbrt'
{
[functions]: ,
__proto__: { },
description: "Object doesn't support property or method 'cbrt'",
message: "Object doesn't support property or method 'cbrt'",
name: "TypeError",
number: -2146827850,
stack: "TypeError: Object doesn't support property or method 'cbrt'
at cielabForwardTransform (eval code:39754:3)
at fromXYZ (eval code:39763:3)
at lighten (eval code:39706:3)
at genVariations (eval code:39696:5)
at parse (eval code:39606:7)
at parsedTheme.get (eval code:39498:7)
at generatedStyles.get (eval code:39466:7)
at Theme.prototype.applyTheme (eval code:39297:5)
at handler (eval code:39449:13)
at Vue.prototype.$watch (eval code:4941:9)",
Symbol(Lang fallback)_i.t81c9tw05xo: undefined,
Symbol(react.element)_h.t81c9tw05xo: undefined,
Symbol(stop)_n.t81c9tw05xo: undefined
}

Maybe a good solution is to switch socket.io to this fork of debug debug-es5 that is transpiled to es5.

I've spent an entire day trying to get babel and webpack to transpile debug/src/browser.js and from the many threads I've stumbled on it seems like a lot of people are running into this too. Seems like a lot of engineering time that could be saved.

By the way, socket.io v2.2.0 has a memory leak that was fixed in 'ws' v7.1.2 (websockets/ws#1617) so be careful downgrading.

Edit: got it fixed
Most posts I found were recommending to stop excluding /node_modules/ from webpack but this didn't work and also is slow. (pretty sure webpack was hitting the file but babel wasn't transpiling it, maybe related to babel/preset-env)

Instead, I just installed debug-es5 and had webpack use that in place of debug by adding this to the webpack.config.js

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

This saved me hours of work - thank you!

I have created a very small repo with this issue solved with basic Webpack configuration: https://github.com/kmaraz/debug-to-es5

The debug dependency was reverted to 3.1.0, which does not need to be transpiled. Released in 2.3.1.

Please note that you can also use the webpack-remove-debug plugin, in order to remove any call to the debug dependency (until we find a proper way to provide a build with and without debug).