IE10 - 'Set' is undefined

[MariuszDabrowski]

Description

Using the Gatsby default starter, if you build the project and preview the built project in IE10 you get the following error:

SCRIPT5009: 'Set' is undefined

Steps to reproduce

1. Setup a new project using Gatsby default starter
2. Build the project using npm run build
3. Start up a web server in the public directory and preview the site using IE10
4. Open up the console and refresh the page to see the error

Environment

Browser testing was done in Browser stack - Win 7 IE 10

[jonniebigodes]

@MariuszDabrowski let me start by saying i'm sorry for the issue you're having, but some tangible issues regarding this type of situation keep being created in here.
As a workaround, i would like for you to add to your gatsby-browser.js the following:

import 'core-js/modules/es6.set'; 
import 'core-js/modules/es6.map';

Be advised that using Gatsby with ie10 in development mode there are some issues regarding hmr (hot module replacement). But for production build adding those imports should resolve your issue.

A little more context on the issue in here

Feel free to provide feedback

[MariuszDabrowski]

@jonniebigodes thank you for the prompt reply.

Still working with Gatsby default starter without any modifications besides adding the code below to gatsby-browser.js:

import 'core-js/modules/es6.set'; 
import 'core-js/modules/es6.map';

After building the project and running a local server on the /public folder a strange issue occurs. The page will load fine without any errors. But it you click on Go to page 2 then on Go back to the homepage, eventually the app crashes on the homepage with the following error:

[jonniebigodes]

@MariuszDabrowski i've been trying to see if i could see what is the problem you're experiencing and i wasn't able to reproduce it.

Now i tested it out with a production build and Gatsby's internal server through gatsby build && gatsby serve, opened edge(as i don't have access to a ie10 anymore) with emulation activated. Opened the page and the result was the following:

Going back and forward always produced the same result, no errors.

I took it a step further, deployed to netlify and applied the same test as above and the results are as you can see below:

To cover my basis, i've added a dummy express server with the following code:

const express= require('express');

const app= express()
app.use(express.static('public'))
app.set('port', process.env.PORT || 5000)

app.get('*', (req, res) => {
    res.sendFile('./public/index.html')
})

app.listen(app.get('port'),error=>{
    if (error){
        console.log('====================================');
        console.error(`error starting server with error:\n${error}`);
        console.log('====================================');
    }
    else{
        console.log('====================================');
        console.info(`dummy express server running @ ${app.get('port')}`)
        console.log('====================================');
    }
})

Added the production build to it. Issued node index.js to start the server, same results.
Took it even further, grabbed the production build and added it to a apache server i have running on a WSL machine, started the server and the same results, no errors.
And finally grabbed the production build and added it to a windows server 2008 RC2 running iis 7.5 and the same results, no errors.

Now after all of this, it led me to two things. One, what kind of server you're using and how you're running it and two, as i have only access to a trial version of browserstack and with that the number of testing options at my disposal are really very limited i'm not sure if the problem is actually with browserstack and how it emulates the os/browser and the versions they emulate, namely to what point in time

[MariuszDabrowski]

@jonniebigodes thank you for the thorough response. I have to admit that I'm not an expert when it comes to the server portion of web apps, but here's what we figured out:

• Running a nginx server caused the same error I was getting above
• Running Python SimpleHTTPServer caused the same error
• Running Gatsby serve didn't cause the error
• Running a separate express server (width your config) also didn't cause the issue

So it looks like the error was happening because the other ways I tried to serve the site weren't redirecting to ./public/index.html on every request - which is what seems to fix the issue. This was only an issue in IE10 - the other server methods I tried were fine in all other browsers.

Thanks again for the help!

[jonniebigodes]

@MariuszDabrowski i factored in what you said and expanded my tests.

• Added ngnix to my wsl installation, running on ubuntu 18.04, created a new folder to test it out and copied over the production build inside, below is the setup i used for nginx to test your issue.
  

On the left is the configuration for the site, on the right the contents of the folder with the Gatsby production build files.

Starting nginx and applying the same tests like before yelded the same results as i mentioned abvode.

• Created a simple Python http server and made it serve the files for the build and no issues whatsoever.

As i'm not aware of the setup you used probably was something related to what you said. It was probably a misconfiguration on the server part. Also no need to thank, glad that i could help out in at least point you in the right direction for solving your issue.

[wardpeet]

Sadly we don't include polyfills for react.
you can enable this by using this plugin https://www.gatsbyjs.org/packages/gatsby-plugin-compile-es6-packages/ and use react-dom. For your use case you'll have to add

{
  resolve: `gatsby-plugin-compile-es6-packages`,
  options: {
    modules: [`react-dom`]
  }
}

We have an issue open to actually look into this
#7064

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!