chore(gatsby): add ie polyfill to webpack entry

[nihgwu]

Description

This PR adds polyfill for IE according to the browserlist config, the current polyfill strategy (useBuiltIns: usage) works well in most cases, but I encountered with errors only on IE in all my sites built with Gatsby, I digged a lot and found that(my guess) it's caused by the polyfill for Symbol, the useBuiltIns: usage doesn't work as React can live without Symbol so it's not polyfilled, but then it's polyfilled if the Symbol is used in other packages, so we have to add the Symbol polyfill before React bootstraps, here is my current solution for my sites https://github.com/Autodesk/react-base-table/blob/master/website/gatsby-node.js#L16

Related Issues

Fixes #7003

[wardpeet]

This PR looks really great! It's a bit weird that babel-polyfill isn't polyfilling. Let me dig into that first before proceeding with this PR.

[nihgwu]

I guess that's because in SSR building, React is being processed but Symbol is not polyfilled as it's optional, React will use a fallback, then processing the third-party packages, Symbol is polyfilled because of useBuiltIns=true (I included the third-party packages for babel-loader), then you deploy the SSR output, React detects mismatch of elements, so I tried to polyfill Symbol before React and it works like a . charm, and I find there are a lot of this kind of errors like reported in #7003 not only in Gatsby, but most of answers are not really helpful, someone found that add @babel/polyfill before the entry solve the problem, but I guess the polyfill for Symbol is the key as other polyfills should work with useBuiltins=true

[nihgwu]

there are ie-mob 10 and ie-mob 11, should we also check for those versions? Personally I don't want to do that

[nihgwu]

Actually we only need to polyfill Set Map Symbol and other polyfills will be done by babel-loader, we could create our own polyfill rules instead of using react-app-polyfill, but I love the best practice from create-react-app

[nihgwu]

@wardpeet any chance to review? the change is relative slight but would save those who are struggling with IE support, especially the Symbol problem which is hard to identify, thanks

[wardpeet]

Hey, sorry for the late response but we rather not make this change. We are more eager to go for #7064. Which will let us babel transform all our plugins which will let babel-polyfill, polyfill all features.

At the moment there is a possible workaround by using https://www.gatsbyjs.org/packages/gatsby-plugin-compile-es6-packages/ and adding react-dom to that list.

We want you to know that we certainly want to keep you as a contributor to Gatsby.

Thanks again, and we look forward to seeing more PRs from you in the future! 💪 💜

[nihgwu]

@wardpeet as I said, even you add those es6 packages to be compiled by babel loader, it won't solve the problem I pointed out, the Symbol polyfill issue, I did add those es6 packages in my project https://github.com/Autodesk/react-base-table/blob/master/website/gatsby-node.js#L35-L38, and it still doesn't help because of that

BTW, I contributed a lot before but was busy with my own stuffs then. I just received my swags today(I got the coupons long before, but just used them last week), they are so good 😄

[nihgwu]

Let me explain a bit more with IE, I'm using an ES6 package react-inspector, so I have to make it transpiled by babel, and that package also uses Symbol and Symbol is polyfilled by babel, but before that no packages use Symbol directly as they fallback if Symbol is not available like var hasSymbol = typeof Symbol === 'function' && Symbol.for;, when I haven't used react-inspector, everything goes fine, as Symbol is not required, but when I navigate to the page used react-inspector the page will crash, because in this page, the Symbol is available since it's polyfilled, but React is initialized without Symbol support before that, so there are mismatches and throw Objects are not valid as a React child (found: object with keys {$$typeof, type, key, ref, props, _owner}).

[pieh]

Hey @nihgwu! Did you by any chance check if #14111 solve the problem? Ideally we could just use that and not add extra babel presets

[nihgwu]

@pieh see my comment here #13241 (comment), that PR just make all the packages transpiled by Babel, but still doesn't solve the Symbol issue I described

[pieh]

@pieh see my comment here #13241 (comment), that PR just make all the packages transpiled by Babel, but still doesn't solve the Symbol issue I described

Hmm, I didn't try it, but if all packages would be transpiled (including React) - wouldn't @babel/preset-env pick up that it needs to polyfill Symbol and that would happen before react-inspector and then both React and react-inspector would use that polyfilled Symbol?

[wardpeet]

#14111 seems to work for react-inspector. Somehow I can't get your example working

[nihgwu]

@wardpeet That PR works for react-inspector for sure, but I guess it should works for my site as well I guess, https://babeljs.io/repl#?babili=false&browsers=last%201%20versions&build=&builtIns=usage&spec=false&loose=true&code_lz=G4QwTgBAFiDODKBPAtgIwPYBsIF4IBdEAHAU3QDMIk0tcc8BycgVwDsBjfAS3VYYgBkAqigyYAdOXRgA3EA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env&prettier=false&targets=&version=7.4.5&externalPlugins=%40babel%2Fplugin-proposal-private-methods%407.4.3%2C%40babel%2Fplugin-proposal-class-properties%407.4.0%2C%40babel%2Fplugin-proposal-object-rest-spread%407.4.3, the Symbol will be polyfilled then in a test expression, so it will be with React, I don't have a windows device to test, btw I updated my website a bit, not sure if it's related to your failure building

[wardpeet]

I've tested #14111 and got your example to work with the babel-loader PR.

Thanks a bunch for tackling this, sadly i'll be closing as babel-loader is a better approach as it will make our live easier when moving #14289 forward.

[nihgwu]

@wardpeet Thanks so much for you for you patients

[wardpeet]

@nihgwu Fix got p in gatsby@2.11.0.

Thank you, for your patience 😉

[nihgwu]

cool, will try, thanks