Gatsby build fails resolving react-icons from studio directory in CI

5 replies
Last updated: Jan 28, 2026
Hi! I have been battling a weird issue with building my Gatsby site in a CI pipeline. The problem seems to be somehow related to the package
react-icons
in my
studio
.
Everything works fine when building the site locally, but in a CI the build fails. I’ve tried building in Netlify as well as Github Actions.

The error I get is following:

success Build manifest and related icons - 1.382s
success onPostBootstrap - 1.391s
info bootstrap finished - 7.327s
success run static queries - 0.069s - 17/17 247.95/s
success run page queries - 0.183s - 68/68 371.98/s
success write out requires - 0.003s
failed Building production JavaScript and CSS bundles - 27.655s
error Generating JavaScript bundles failed

Can't resolve 'react-icons/fi' in '/home/runner/work/site-name/studio/schemas/objects/sections'

If you're trying to use a package make sure that 'react-icons/fi' is installed. If you're trying to use a local file make sure that the path is correct.
I have
react-icons
installed in both
web
and
studio
. Do you have any idea why this is happening? Why does
gatsby build
try to resolve modules from another directory?
AI Update

This is a classic monorepo/workspace issue where Gatsby's build process is crawling into your Studio directory and attempting to resolve imports it finds in your schema files. The key question is: why is Gatsby even looking at your Studio schemas?

The most likely culprit is that you're importing or referencing something from your Studio schemas in your Gatsby site code, or Gatsby's webpack configuration is inadvertently including the Studio directory in its module resolution scope.

Here's how to fix this:

1. Verify You're Not Importing Studio Schemas Directly

First, check if your Gatsby code (web directory) is importing anything from studio/schemas. Search your web codebase for imports like:

import something from '../../studio/schemas/...'

If you find any, remove them. Your Gatsby site should only consume content from Sanity via gatsby-source-sanity, not by importing schema files directly.

2. Configure Webpack to Exclude Studio Directory

Add this to your gatsby-node.js to explicitly tell webpack to ignore your Studio folder:

exports.onCreateWebpackConfig = ({ actions }) => {
  actions.setWebpackConfig({
    resolve: {
      alias: {
        // Prevent webpack from resolving studio directory
        '../studio': false,
        '../../studio': false,
      }
    }
  })
}

Or use webpack's externals configuration:

exports.onCreateWebpackConfig = ({ actions, stage }) => {
  if (stage === 'build-javascript' || stage === 'build-html') {
    actions.setWebpackConfig({
      externals: {
        'react-icons/fi': 'react-icons/fi'
      }
    })
  }
}

3. Adjust Your Monorepo Structure

If you're using npm/yarn workspaces, ensure your workspace configuration properly isolates the projects. In your root package.json:

{
  "private": true,
  "workspaces": [
    "web",
    "studio"
  ]
}

Make sure your Gatsby build command runs from within the web directory, not from the root:

cd web && gatsby build

4. Check Your .gitignore and Build Configuration

CI environments might be handling symlinks or hoisted dependencies differently than your local machine. Ensure your CI build:

  • Installs dependencies in both web and studio directories
  • Runs the build from the correct working directory
  • Doesn't have different NODE_ENV or path resolution settings

If you need an immediate fix, install react-icons in your web project:

cd web
npm install react-icons

This works around the resolution issue but doesn't address the root cause.

The real solution is #1 and #2 combined: ensure your Gatsby site isn't importing Studio code, and configure webpack to ignore the Studio directory entirely. Your Studio schemas shouldn't be part of your Gatsby build process—Gatsby should only interact with Sanity through the gatsby-source-sanity plugin to fetch content via the Content Lake API.

Show original thread
5 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?