Get rid of core-js polyfill added in 4.0.0.beta-2

[dispalt]

• This is a bug
• This is a modification request

Code

// webpack.config.js

// additional code, remove if not needed.

Please paste the results of webpack-cli info here, and mention other relevant information

Expected Behavior

It works with IE11

Actual Behavior

I am getting a stack out of space error on IE11 which I think is because of recursion of my core-js symbol polyfill conflicting with your core-js during the Symbol polyfill

For Bugs; How can we reproduce the behavior?

Since you ask users to polyfill Promise and I think my Symbol polyfill is stepping on your Symbol polyfill maybe the best way is to skip using that and just tell people webpack-dev-server client needs to be transpiled if you want to use it in an old browser. I tested it with the polyfill I am getting a stack out of space error, without a polyfill it works.

For Features; What is the motivation and/or use-case for the feature?

[alexander-akait]

Without this polyfill IE11 will not work

[alexander-akait]

Please provide steps to reproduce

[dispalt]

I thought I had it working and now I can't figure it out, uggh.

I guess what led me down this path is trying this with IE11

• First I tried to use it with IE11 and it would throw a receiver error (I think my babel loader was recompiling it)
• Second I got past that by putting webpack-dev-server in the babel loader ignore,
• Third I landed on the error I can't get past which is Out of stack space.

All these errors seem to appear mostly when polyfills are stepping over each other, which I kinda assumed is happening because I am using preset-env with ie11, corejs: 3 and entry mode.

Now I am starting to doubt this is the issue... I can't reliably get it working again =(

[alexander-akait]

Firstly please update to beta.3

Third I landed on the error I can't get past which is Out of stack space.

Do you have stacktrace? I really can't reproduce it, also you can try to test it locally, go to node_modules/webpack-dev-server/client/log.js and comment require('../modules/logger'), also change log: logger.getLogger(name) on log: console and comment logger.configureDefaultLogger then run dev server

[alexander-akait]

I think more and more that we need to remove IE11 from support...

[dispalt]

Yeah ie11 is such a pain and WDS makes it so much better. Removing the logging definitely works, FWIW

[alexander-akait]

So problems with polyfill?

[dispalt]

yeah my original thought was that the polyfill added in the 4.x series is interfering with the polyfill that I include, but I haven't been able to confirm it, because if I remove your polyfill it still doesn't work.

zloirock/core-js#735

[alexander-akait]

Maybe you can provide test repo?

[dispalt]

Yeah I will work on that, thanks for all the help. One last question and I think this might clear up a lot for me.

So during the bundling phase the webpack babel-loader processes the webpack-dev-server files after my entrypoint, but I think the webpack-dev-server code is getting called before my code, is that correct?

I can't quite figure out the order of everything. Because if it was getting called after my code it wouldn't an issue since the core-js import in my project would have polyfilled Symbol

[alexander-akait]

So during the bundling phase the webpack babel-loader processes the webpack-dev-server files after my entrypoint, but I think the webpack-dev-server code is getting called before my code, is that correct?

Sorry, I don't undestand, all files handled by babel-loader (if you don't set exclude) before running webpack-dev-server

[dispalt]

I guess what I am suggesting is don't include the core-js polyfills, and instead make the user of webpack-dev-server who wants to use in IE11 polyfill it themselves, similar to how you're telling them to polyfill promise.

This is assuming if I do something like

main.js

import { Foo } from "foo.js";
Foo.main();

if (module.hot) {
  module.hot.accept();
}

entry: {
  main: [
    'core-js/stable',
    'regenerator-runtime/runtime',
    'main.js', // my actual file
  ]
}
...
{
          test: /\.(js|jsx)$/, // don't exclude anything.  This means it would process anything from the webpack-dev-server client code
          use: {
            loader: 'babel-loader',
            options: {
              babelrc: false,
              configFile: path.resolve(__dirname, 'babel.config.js'),
              compact: false,
              cacheDirectory: true,
              sourceMaps: false,
            }
          }
        },

Unless webpack dev server client code works differently, wouldn't this be the right solution?

[dispalt]

So this works great now with IE11! Just gave rc0 a spin, it works great (even in ie11), thank you!