gatsbyjs/gatsby · error

Error in "${modulePath}":

Error message

Error in "${modulePath}":

What it means

Thrown by resolve-module-exports when dynamically importing a plugin module succeeds in resolution but throws a non-test error at require/import time. The handler checks testImportError (errors considered acceptable to ignore); if it is not ignorable, it panics with the module path and the original error so the user sees the cause. This is the runtime-error-on-import branch, distinct from the SyntaxError branch.

Source

Thrown at packages/gatsby/src/bootstrap/resolve-module-exports.ts:232

      if (!moduleFilePath) {
        return []
      }

      const rawImportedModule = await import(
        maybeAddFileProtocol(moduleFilePath)
      )

      // If the module is cjs, the properties we care about are nested under a top-level `default` property
      const importedModule = preferDefault(rawImportedModule)

      return Object.keys(importedModule).filter(
        exportName => exportName !== `__esModule`
      )
    } catch (error) {
      if (!testImportError(modulePath, error)) {
        // if module exists, but requiring it cause errors,
        // show the error to the user and terminate build
        report.panic(`Error in "${modulePath}":`, error)
      }
    }
  } else {
    return staticallyAnalyzeExports(modulePath, resolver)
  }

  return []
}

View on GitHub (pinned to 8b06340921)

Solutions

1. Inspect the attached `error` object in the panic output: it carries the original thrown error and stack from inside the module.
2. Open modulePath and fix the top-level code that throws, or wrap it so it only runs inside the intended lifecycle hook.
3. Ensure all dependencies the module imports at top level are installed and resolvable.
4. If the module is incompatible with the Gatsby version, pin a compatible version or update the module.

// Detect import-time failures in your own plugin modules during dev
try {
  require(modulePath)
} catch (e) {
  console.error('Plugin import failed:', e)
}

// Wrap the dynamic import to capture the original error:
try {
  const mod = await import(modulePath)
} catch (e) {
  console.error(`Import of ${modulePath} threw`, e)
  throw e
}

When it happens

Trigger: Importing the module triggers code execution that throws (e.g. the module calls a missing function at top level, references undefined config, or fails an assertion); testImportError returns false so the error is surfaced rather than swallowed.

Common situations: A plugin module references process.env values or filesystem paths that only exist at runtime; top-level code in the module throws because a dependency it expects is not installed; the module uses an API removed in the current Gatsby version.

Related errors

• 112003
• Syntax error in "${absPath}":\n${err.message}\n${codeFrame}
• This plugin file is using both CommonJS and ES6 module syste
• Usage of "cache" instance in "onPreInit" API is not supporte
• No worker function found for ${job.name}

AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13). Data as JSON: /api/errors/21e278a185dd35cc. Report an issue: GitHub.