gatsby: Cannot read property 'Provider' of undefined. BaseContext from `@reach/router` is undefined.

Hi! It’s over two years now and I also still have this bug. Is there any way we can help?

pnpm install @gatsbyjs/reach-router does work

Hello , I am facing same exact issue! any fix or help , please ?

I am getting this error now when running a normal yarn dev on my pc, not docker. Have spent a few hours trying anything to solve.

Gatsby dependency bugs are hitting us VERY BAD. As normal with these bugs the issue is closed because of course there is no simple was to create a minimal reproduction.

I encountered this issue in the process of upgrading a project from Gatsby v2 to v4, and put a bunch of console logs in some places to try to understand what was happening. I was able to arrive at a solution that doesn’t require editing node_modules, and I hope it may shed some light on why this is happening in the first place.

TL;DR Cause — The reach-router-add-basecontext-export-loader is adding the needed export to @gatsby/reach-router/es/index.js but not to @gatsby/reach-router/index.js, and the latter is what Gatsby is importing (in my case, at least).

TL;DR Fix/Workaround — Create your own basic loader to add the export, just like the Gatsby team did for the other file. Code below.

I wouldn’t call myself a Gatsby pro, so I don’t know why Gatsby in my project is using /index.js instead of /es/index.js. I’m on Node 16 LTS, if that matters. The fact that reach-router-add-basecontext-export-loader addresses this problem, but only for /es/index.js, suggests that either my Gatsby project is importing the router wrongly somehow (and perhaps some other people’s projects are not, hence difficulty reproducing), or that certain projects legitimately import the router this way, and not having a built-in BaseContext patch for it like the other path does is simply an oversight.

Hopefully this information can be useful in figuring out the underlying problem. But in the meantime, the issue can be worked around by doing the same thing the Gatsby team did: create a loader that adds the export at build time. In my case, I created my own reach-router-add-basecontext-export-loader.js at the root of my project with the appropriate export format (it’s different from what the ES version needs):

exports.default = function (source) {
    if (source.includes("exports.BaseContext")) {
        return source;
    } else {
        return source + "exports.BaseContext = BaseContext;";
    }
}

And then added it to the Webpack config via actions.setWebpackConfig in gatsby-node.js, making sure to test for the reach-router/index.js rather than reach-router/es/index.js:

actions.setWebpackConfig({
    module: {
        rules: [
            {
                test: require.resolve(`@gatsbyjs/reach-router/index`),
                type: `javascript/auto`,
                use: [
                    {
                        loader: require.resolve(`./reach-router-add-basecontext-export-loader`),
                    },
                ],
            },
        ],
    },
});

This yields the same effect in the build as manually adding the export to the file in node_modules, but without the complications of patching node_modules. I hope it’s helpful for anyone else who runs into this until the bug is truly resolved.

@ascorbic, @vladar, and @pieh , I had the same issue and ran gatsby build --no-uglify. This was my warning:

warn ./.cache/production-app.js
Attempted import error: 'BaseContext' is not exported from
'@gatsbyjs/reach-router' (imported as 'BaseContext').

I went into @gatsby/reach-router/index.js and added exports.BaseContext = BaseContext; to the final line of the file and it seems to build well now. Not sure why this only is happening for @shrirambalaji and myself though. I also have some custom webpack configs