gatsby: WebpackError: self is not defined

Hi there, turns out you can use a null loader to allow it to build properly. Worked for me with firebase, at least:

In gatsby-node:

exports.onCreateWebpackConfig = ({actions, stage}) => {
    if (stage === "build-html") {
        actions.setWebpackConfig({
            module: {
                rules: [
                    {
                        test: /firebase/,
                        use: ['null-loader']
                    },
                ],
            }
        })
    }
};

Awesome! Thank you! I have also found another solve for this issue,

1. Delete node_modules
2. run npm i whatwg-fetch@2.0.4 --save
3. run npm install

importing it into the gatsby-browser.js file fixed it for me.

I came to this thread due to whatwg-fetch causing me similar issues (however I am not using Firebase). With one version, it would work in build but not develop. Downgrading from 3.0.0 to 2.0.4 caused the opposite, failing build and working in develop. Details in my comment in a similar issue: https://github.com/gatsbyjs/gatsby/issues/3006#issuecomment-459540756.

Summary: I switched to fetch-ponyfill and it worked in both scenarios.

Sure, use gatsby-plugin-layout. And the key implementation is in https://github.com/muhajirframe/gatsby-starter-firebase/blob/master/src/layouts/index.js .

Basicly it load firebase on componentDidMount(). And put firebase in react context that’s it.

Same issue with whatwg-fetch, 2.0.4 → 3.0.0.

@adberard the issue was caused by ‘window’ not being defined in a gatsby build. I had imported ‘whatwg-fetch’ in a javascript file like normal but it needs adding to the gatsby-browser.js file here.

import ‘whatwg-fetch’

I’m assuming firebase has the same issue where it’s using fetch internally and using the library in a gatsby project is causing the same issue.

FWIW to future visitors of this thread, in response to my previous post, gatsby-plugin-layout and putting a firebase instance into context are not necessary steps to solving the issue of loading the Firebase SDK with Gatsby. Dynamic importing is necessary. Here’s why.

Firebase has an initializeApp method that makes reference to the window object. Gatsby does not have access to the window object in its build phase. Thus, we need to delay the initialization of Firebase until we have access to that object. Dynamically importing it in a component’s componentDidMount lifecycle hook guarantees this. However, this is not the end of solving the problem.

The reason context was used, but isn’t the only means of solving this problem, is to create a Firebase singleton in your application, that is, only one instance of initialized Firebase being consumed by your app. If you’re going to dynamically import and then initialize Firebase in the client, you will have to come up with a strategy to guarantee you only initialize one instance and use it through out your app. The example above by @muhajirframe does show an example with the getFirebase function.

Best of luck getting this working. I wrote about it in a blog post should you want more details of how I solved this problem: https://kyleshevlin.com/firebase-and-gatsby-together-at-last.