Next.js 12.0.2 + Framer 5.0.1 leading to errors in production

[sambecker]

What version of Next.js are you using?

12.0.2

What version of Node.js are you using?

14.16.0

What browser are you using?

Chrome 95

What operating system are you using?

macOS

How are you deploying your application?

Vercel

Describe the Bug

Seeing a 500 application error when deploying app to Vercel with the following dependencies:

• next: 12.0.2
• framer: 5.0.1

App deploys fine with next: 12.0.1

Vercel error logs below:

2021-11-01T16:43:25.167Z	76a0eb5e-e736-404e-b454-15468c5f94c2	ERROR	file:///var/task/node_modules/framer-motion/dist/es/context/LazyContext.mjs:1
import { createContext } from 'react';
         ^^^^^^^^^^^^^
SyntaxError: Named export 'createContext' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'react';
const { createContext } = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:97:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:142:20)
    at async Loader.import (internal/modules/esm/loader.js:182:24)
2021-11-01T16:43:25.168Z	76a0eb5e-e736-404e-b454-15468c5f94c2	ERROR	file:///var/task/node_modules/framer-motion/dist/es/context/LazyContext.mjs:1
import { createContext } from 'react';
         ^^^^^^^^^^^^^
SyntaxError: Named export 'createContext' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'react';
const { createContext } = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:97:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:142:20)
    at async Loader.import (internal/modules/esm/loader.js:182:24) {
  page: '/'
}
RequestId: 76a0eb5e-e736-404e-b454-15468c5f94c2 Error: Runtime exited with error: exit status 1
Runtime.ExitError

Expected Behavior

Production environment should mimic development, i.e., not crash

To Reproduce

Does not reproduce locally—only seeing on Vercel in production

[KevinShiCA]

Seeing this as well, there's a "minimal" reproducible repository here: https://github.com/jokull/next12-react-form-test/blob/main/pages/index.js - this uses @shopify/react-form which also uses named imports from React, so not Framer exactly but the same idea (maybe change the title of the issue?).

I think any dependency that does things like import {useState} from 'react'; instead of import React from 'react'; React.useState(...); will see this on Next 12. It also doesn't have to be 'react' specifically, any ESM module importing CJS modules using named imports will suffice.

Weirdly enough this doesn't seem to have anything to do with SWC - I've tried this both with and without a custom babel config file (which disables SWC on Next@12) and the error is the same either way. Seems to be something else that happens behind the scenes in Next@12, I'm reverting to Next@11 for now.

I've also seen this sporadically in development (the above linked repo is consistent in development), I think it most likely works locally sometimes because of next's build cache, though I'm not sure.

[sambecker]

@KevinShiCA thanks for building on this. Are you saying if dependencies used import React from 'react' that would mitigate the issue? Aren't named (vs global) imports optimal? Do you have a theory as to why this works in Next.js 12.0.1 but not 12.0.2?

[KevinShiCA]

Hah, I actually never bothered trying 12.0.1. It works for me, thanks for that!

I'm convinced it's this PR: #30427.

I tried out the various canary versions that led up to Next@12.0.2, and even Next@12.0.2-canary.0 will cause this. There are only 3 core changes that went in between 12.0.2-canary.0 and 12.0.1, and the other two are a tsconfig fix and a SWC bump, both of which should be unrelated. The above PR does indeed change a bunch of stuff in Next's base webpack config relating to ESM loading.

/cc @sokra who authored that PR

Aren't named (vs global) imports optimal?

Yes, but ESM and CJS have a hell of a time interoping together. Here's a great article about it: https://simonplend.com/node-js-now-supports-named-imports-from-commonjs-modules-but-what-does-that-mean/

Unfortunately React only provides a CJS build. The community was hoping for an ESM build to come in React 18, but it sounds like it's going to come in version 19 or later.

[shaneosullivan]

Downgrading to 12.0.1 worked for me too. This was a nasty bug to ship, where a site completely fails but only in production. How can this type of error be caught in the future? What tests were missing that allowed it to ship? As someone whose business depends on NextJS & Vercel, I'd love to see a retrospective on this issue to identify the gap in quality control and the mitigation steps being put in place to prevent a re-occurrence.

[sambecker]

Thanks for all this background @KevinShiCA! Super helpful. Any suspicions why this works locally but not hosted (on Vercel)?

[jadbox]

I'm having the same issues with importing hooks on 12.0.2.

[jpbow]

Same kinds of errors here but happens when using next@12.0.2 with react-hook-form@7.12.1

Luckily it failed for me in local dev instead of in production. Also reverted to next@12.0.1 to resolve the issue for now.

[jadbox]

It seems that it's SSR is broken for rendering hooks. Any hook I import on SSR gets imported as undefined.

[laurence-myers]

Same kinds of errors here but happens when using next@12.0.2 with react-hook-form@7.12.1

Luckily it failed for me in local dev instead of in production. Also reverted to next@12.0.1 to resolve the issue for now.

I had an issue, where Next.js built the code for Production just fine, but loading the page would seem to have no React components. Submitting the form would just do a simple HTML submit (reload the page, with form inputs as query string params).

Downgrading to v12.0.1 seems to fix the issue.

[sokra]

I'll look into the repro.

If this is related to ESM externals, instead of downgrading Next.js you can temporary disable experimental.esmExternals: false to prefer the CommonJs version of node_modules like Next.js 11 did.

[sokra]

@KevinShiCA Regarding @shopify/react-form:

It claims to provide a version compatible with Node.js ESM (it has an "exports" field that points to a .mjs file).
But only most of the referenced files have the .mjs extension. The referenced file @shopify/react-form/build/esm/_virtual/_rollupPluginBabelHelpers.js doesn't have the correct extension, so Node.js doesn't treat it as ESM.
That leads to this error:

$ node -e "import('@shopify/react-form')"
(node:30304) UnhandledPromiseRejectionWarning: file:///...@shopify/react-form/build/esm/hooks/field/reducer.mjs:1
import { objectSpread2 as _objectSpread2 } from '../../_virtual/_rollupPluginBabelHelpers.js';
         ^^^^^^^^^^^^^
SyntaxError: Named export 'objectSpread2' not found. The requested module '../../_virtual/_rollupPluginBabelHelpers.js' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '../../_virtual/_rollupPluginBabelHelpers.js';
const { objectSpread2: _objectSpread2 } = pkg;

    at ModuleJob._instantiate (internal/modules/esm/module_job.js:124:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:179:5)
    at async Loader.import (internal/modules/esm/loader.js:178:24)
    at async importModuleDynamicallyWrapper (internal/vm/module.js:451:15)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:30304) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:30304) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This should be fixed in the @shopify/react-form package. Please report it there. cc @michenly

---

import { createContext } from 'react' is fine instead, if it's really react that is installed here. I have seen reports where react has been replaced with preact and that caused this error. @developit is working on that. If this is not related to preact, please provide a reproduction @sambecker

---

PS: Please try experimental.esmExternals: false as workaround.

[nickrttn]

I'm seeing similar errors in the latest version of zustand when combined with 12.0.2

file:///<project-path>/node_modules/zustand/esm/index.mjs:1
import { useReducer, useRef, useEffect, useLayoutEffect } from 'react';
                     ^^^^^^
SyntaxError: Named export 'useRef' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'react';
const { useReducer, useRef, useEffect, useLayoutEffect } = pkg;

    at ModuleJob._instantiate (internal/modules/esm/module_job.js:104:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:149:5)
    at async Loader.import (internal/modules/esm/loader.js:177:24)
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
file:///<project-path>/zustand/esm/index.mjs:1
import { useReducer, useRef, useEffect, useLayoutEffect } from 'react';
                     ^^^^^^
SyntaxError: Named export 'useRef' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'react';
const { useReducer, useRef, useEffect, useLayoutEffect } = pkg;

    at ModuleJob._instantiate (internal/modules/esm/module_job.js:104:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:149:5)
    at async Loader.import (internal/modules/esm/loader.js:177:24)
error - unhandledRejection: SyntaxError: Named export 'useRef' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'react';
const { useReducer, useRef, useEffect, useLayoutEffect } = pkg;

[michenly]

I will take a look at @shopify/react-form soon, thanks for the tag @sokra

Internally we were just having a debate about if any of our open source packages are being use by folks outside of Shopify so this is very cool to see 😄

[sambecker]

@sokra just posted a minimal example!
https://github.com/sambecker/nexttest

Interestingly, this works fine until the last commit (Convert home component to SSR).

As before, this all works in development—only crashes in production.

Good luck!

[jokull]

Hey @michenly

Internally we were just having a debate about if any of our open source packages are being use by folks outside of Shopify so this is very cool to see 😄

Just wanted to let you know we love @shopify/react-form. Use it extensively. Did a bunch of research for different forms library and have been very happy with picking this.

[BPScott]

puts on Shopify employee hat

@sokra thank you for that investigation. I've identified the root cause as coming from our rollup babel plugin - it's not allowing us to rename the file its helpers live in. I've documented the root cause at rollup/plugins#1031.

[ijjk]

Hi, this has been updated in v12.0.3-canary.2 of Next.js, please update and give it a try!

[sambecker]

Just updated my example repo to v12.0.3-canary.2 and it works!
https://github.com/sambecker/nexttest

Thanks @ijjk + @sokra!

[KevinShiCA]

Confirmed that v12.0.3-canary.2 works without experimental.esmExternals: false in my next config. Thanks all!

[amuttsch]

react-hook-form/resolvers#271 does not work with v12.0.3-canary.2. I get the error SyntaxError: Named export 'set' not found. The requested module 'react-hook-form' is a CommonJS module, which may not support all module.exports as named exports..

Changing the import from import { yupResolver } from '@hookform/resolvers/yup'; to import { yupResolver } from '@hookform/resolvers/yup/dist/yup'; is a workaround that fixes this issue.

Edit: v12.0.3-canary.5 also fails while collecting page data with the above error.

[kristjanmar]

I'm having the same problem with Zustand. I downgraded Next to 12.0.1 and it works now.

2021-11-04T09:56:47.575Z ERROR file:///var/task/node_modules/zustand/esm/index.mjs:1 import { useReducer, useRef, useDebugValue, useEffect, useLayoutEffect } from 'react'; ^^^^^^ SyntaxError: Named export 'useRef' not found. The requested module 'react' is a CommonJS module, which may not support all module.exports as named exports.

[yaunghein]

I was also having the same errors in the production, then I changed the version of nextjs to next@12.0.1 and now it works perfectly I was also using framer-motion.

Yesssssss, I'm facing this issue , but now it works when I downgrade to next@12.0.1. Thanks you and everyone in this conversation.

[webda2l]

For note, with v12.0.4 & react-hook-form, it's only ok with esmExternals: false

And to avoid issue with npm run dev (strange error about outdated code), I advice for now:
esmExternals: process.env.NODE_ENV === 'DEVELOPEMENT'

[daniel-stockman-lark]

Using patch-package, this fixed it for me (with react-hook-form@7.21.0):

diff --git a/node_modules/react-hook-form/dist/index.esm.js b/node_modules/react-hook-form/dist/index.mjs
similarity index 100%
rename from node_modules/react-hook-form/dist/index.esm.js
rename to node_modules/react-hook-form/dist/index.mjs
diff --git a/node_modules/react-hook-form/package.json b/node_modules/react-hook-form/package.json
index 579ab00..1e1c18e 100644
--- a/node_modules/react-hook-form/package.json
+++ b/node_modules/react-hook-form/package.json
@@ -3,11 +3,11 @@
   "description": "Performant, flexible and extensible forms library for React Hooks",
   "version": "7.21.0",
   "main": "dist/index.cjs.js",
-  "module": "dist/index.esm.js",
+  "module": "dist/index.mjs",
   "umd:main": "dist/index.umd.js",
   "unpkg": "dist/index.umd.js",
   "jsdelivr": "dist/index.umd.js",
-  "jsnext:main": "dist/index.esm.js",
+  "jsnext:main": "dist/index.mjs",
   "source": "src/index.ts",
   "types": "dist/index.d.ts",
   "sideEffects": true,
@@ -18,7 +18,7 @@
   "exports": {
     "./package.json": "./package.json",
     ".": {
-      "import": "./dist/index.esm.js",
+      "import": "./dist/index.mjs",
       "require": "./dist/index.cjs.js"
     }
   },

Basically, the import target needs to use the .mjs extension, preserving the default type of CommonJS for the overall package.

[hpohlmeyer]

The fix from @daniel-stockman-lark for react-hook-form has been implemented the other day but rolled back because of compatibility issues with CRA. @yordis has summarized the problem here: react-hook-form/resolvers#271 (comment)

[michenly]

FYI, @BPScott had added fix to @shopify/react-form@1.1.8 + (you can now find @shopify/react-form/build/esm/_virtual/_rollupPluginBabelHelpers.mjs file)

cc @KevinShiCA @jokull

[bluebill1049]

Potential issue: we have a user reported 12.0.9 (still in beta) is introducing a regression on this issue after the last patch which we made in hook form react-hook-form/resolvers#337 (comment) Curious to know what's changing, what do we need to prepare for this?

[balazsorban44]

Hi, as the OP stated in #30750 (comment)
and someone else confirmed (even using a different library than OP) in #30750 (comment)

Next.js should now work with Framer (and presumably with other properly configured libraries), which this issue was opened about.

I tried to look for other reproductions after the OP confirmed the issue is fixed, but I only see other libraries being reported with similar issues, and some of them acknowledged the problem is on their side and have patched it already.

I cannot fully see if all concerns have been addressed for the others (other than @bluebill1049, do you know if the issue still happens?), but to make any potential remaining problem easier to track/fix, I would like to ask those who have this kind of issue to test their code using our next@canary (without the esmExternals config as it's not needed) version and their library's latest version to avoid any doubt, and if the issue still reproduces for you, please post your reproduction repository (preferably as a new issue) and we will investigate!

I'll keep this issue open for a while still, so anyone can comment on their concerns, but after that, I would like to consider this specific issue (about Next.js and Framer) to be closed.

This helps us track down if the issue is indeed in Next.js or a certain library. Thank you! 🙏

[bluebill1049]

Thanks for the follow-up @balazsorban44. The original issue was posted and has not gotten any more response and we suspect it to do with his own setup. I am going to close that issue there and follow up if other issues related pop up again.

[Amar-Gill]

chiming in -- next@12.0.10 and next@12.1.0 are incompatible with zustand@3.7.0

> next build

info  - Checking validity of types  
info  - Creating an optimized production build  
info  - Compiled successfully

> Build error occurred
file:///Users/amardeepgill/personal-projects/ifrit/node_modules/zustand/esm/index.mjs:1
import { useReducer, useRef, useDebugValue, useEffect, useLayoutEffect } from 'react';
                     ^^^^^^
SyntaxError: The requested module 'react' is expected to be of type CommonJS, which does not support named exports. CommonJS modules can be imported by importing the default export.
For example:
import pkg from 'react';
const { useReducer, useRef, useDebugValue, useEffect, useLayoutEffect } = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:98:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:137:5)
    at async Loader.import (internal/modules/esm/loader.js:165:24) {
  type: 'SyntaxError'
}

Downgrading to 12.0.1 does build however.

Edit: looks to fail builds starting from next@12.0.2

[balazsorban44]

@Amar-Gill please read #30750 (comment) Using the with-zustand example did not reproduce your described issue for me locally either. Both build and dev worked fine. 🤔

I'm closing this issue now. Any similar issues should be opened as a separate bug report, attaching a reproduction, after testing with the canary version of Next.js. Feel free to reference this issue in the new one, if you think there is useful context here!

Thanks 🙏

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.