Node 19.3.0 causing Sanity build error with webpack module parsing

13 replies

Last updated: Nov 29, 2025

Following up on build errors I was running into recently – I’ve tried deploying the Next.js Personal Website template to vercel without any issue, but when I go to clone it to my local machine and run

yarn build

i get the following error

Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (61:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See <https://webpack.js.org/concepts#loaders>
| function _toPropertyKey(arg) { var key = _toPrimitive(arg, "string"); return typeof key === "symbol" ? key : String(key); }
| function _toPrimitive(input, hint) { if (typeof input !== "object" || input === null) return input; var prim = input[Symbol.toPrimitive]; if (prim !== undefined) { var res = prim.call(input, hint || "default"); if (typeof res !== "object") return res; throw new TypeError("@@toPrimitive must return a primitive value."); } return (hint === "string" ? String : Number)(input); }
> import { jsx, jsxs, Fragment } from 'react/jsx-runtime';
| import { useMemo, useState, useRef, useEffect, createContext, useContext, useLayoutEffect, forwardRef, useId, useCallback, cloneElement, isValidElement, createElement, Component, memo, useReducer, Children, Fragment as Fragment$1 } from 'react';
| import ReactIs, { isElement as isElement$1, isFragment, isValidElementType } from 'react-is';

Import trace for requested module:
./node_modules/@sanity/ui/dist/index.esm.js
./node_modules/sanity/lib/index.esm.js
./sanity.config.ts
./app/studio/[[...index]]/page.tsx

I’m wondering if anyone else has experienced this error on build. There must be some issue with my development environment though I can’t seem to trace it. I’m running Node 19.3.0

AI Update

This is a classic Next.js + Sanity configuration issue that's been reported before. The error you're seeing happens because Next.js needs to transpile certain Sanity packages (specifically @sanity/ui) that are distributed as ESM (ES Module) files.

Based on the community discussion around this exact issue, there are two solutions:

Solution 1: Configure transpilePackages (Recommended)

Add transpilePackages to your next.config.js or next.config.mjs:

/** @type {import('next').NextConfig} */
const config = {
  transpilePackages: ['@sanity/ui', '@sanity/icons'],
  // ... rest of your config
}

module.exports = config

Or if using next.config.mjs:

/** @type {import('next').NextConfig} */
const config = {
  transpilePackages: ['@sanity/ui', '@sanity/icons'],
  // ... rest of your config
}

export default config

This tells Next.js to transpile these specific packages during the build process, which resolves the "sourceType: module" error.

Solution 2: Pin @sanity/ui version (Temporary workaround)

If you're using Yarn, you can add a resolution to your package.json:

"resolutions": {
  "@sanity/ui": "1.0.5"
}

Then delete your node_modules and yarn.lock, and run yarn install again. This was the workaround suggested when the issue first appeared with @sanity/ui@1.0.6.

About your Node version

You mentioned running Node 19.3.0 - this could be contributing to the issue. Node 19 is an odd-numbered release that's no longer maintained. I'd strongly recommend switching to:

Node 18 LTS (minimum for Sanity Studio v3)
Node 20 LTS (required for Studio v4, which you'll need eventually)

Why it works on Vercel but not locally

Vercel's build environment may have different default configurations or webpack settings that handle ESM imports differently. The transpilePackages configuration ensures consistent behavior across all environments.

After making these changes, delete your .next folder and run yarn build again. The transpilePackages solution is the proper long-term fix, while the version pinning is just a temporary workaround.

Show original thread

13 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.

Get started for free Explore the demo