I don’t think so, as it’s work I’m doing for a company, but I can share what breaks it.
I’m using a Prismic CMS and the @primicio/client package. It uses the native fetch under the hood, which is the fetch provided by NextJS in this instance.
When I call fetch without any next options, it works fine, since it’s generating static content. The problem comes when I provide the following options:
fetchOptions: {
next: {
revalidate: 60 * 60,
}
}
The idea is that I want it to revalidate the content in an hour. In this instance, I see the error in the ISR Handler function.
I’ve also tried
fetchOptions: {
cache: 'no-cache'
}
Which will never cache the response. In this instance, I see the error in the SSR Handler function.
I can also see server.edge is exported in the main branch of react-dom
Based on the current analysis, v4.39.1 should have fixed most if not all use-cases. So yours currently appears to be an unknown or untested edge-case. Devs will now try to analyse and reproduce this further to see if they can find a solution or if it’s a React/Next.js issue as you feel.
I’m still getting a 500 server error on v.4.39.1. My project uses dynamic routes for i18n. Here’s my SSR handler log:
Jul 12, 09:54:03 AM: e52ee9f1 ERROR Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './server.edge' is not defined by "exports" in /var/task/node_modules/react-dom/package.json
at new NodeError (node:internal/errors:399:5)
at exportsNotFound (node:internal/modules/esm/resolve:366:10)
at packageExportsResolve (node:internal/modules/esm/resolve:702:9)
at resolveExports (node:internal/modules/cjs/loader:565:36)
at Module._findPath (node:internal/modules/cjs/loader:634:31)
at Module._resolveFilename (node:internal/modules/cjs/loader:1061:27)
at /var/task/.netlify/functions-internal/___netlify-handler/requireHooks.js:100:40
at Module._load (node:internal/modules/cjs/loader:920:27)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18) {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
@hrishikesh can you check our site?
In my case i have 500 error in some req to api links.
Now in production we have correct deploy with downgraded “@netlify/plugin-nextjs”: “^4.36.1”,
But in new deploys we have 500 errors.
And upgrade to 4.39.1 didin’t help us.
This is completely un-related to this thread. It could be due to a plugin version roll-out on the split API paths, but that’s a separate issue. I’ll escalate this issue accordingly.
Maybe it will be easier for you from this information, now I have tried downgrade version 4.36.1 again - and everything works for me with this version, and with versions 4.38~4.39 I get errors.
I’m seeing the same issue with 4.39.1 on my site. The site id is 95b624a8-99c7-4ed4-8d54-ce77863bc823 and an example that triggers the error can be seen by causing a 404 on beehive.gay, e.g. https://beehive.gay/invalid
@alexzed, could you try deploying again with any of the newset versions? The problem you were seeing yesterday should be resolved. Then, if you continue to receive the serve.edge error, we can discuss accordingly.
Thank you for the report @olivvybee, we’re investigating more use-cases. Once we release a new version to fix those, we will let you know so you can re-try.
@hrishikesh I have some more information about what could be going wrong…
The error states the path .netlify/functions-serve/.unzipped/___netlify-odb-handler/node_modules/react-dom/package.json that does not have server.edge exported, which is correct.
However
It shouldn’t be looking there for it, it should be looking at the next bundled version of react-dom .netlify/functions-serve/.unzipped/___netlify-odb-handler/node_modules/next/dist/compiled/react-dom/package.json - which indeed has everything that is needed.
It looks like somewhere, I don’t know where, the handler is looking to the wrong react-dom for nextjs.
@nick.howard, thank you for that. But, for some context, this is all to do with React being absorbed into Next.js. For App Router, Next.js now uses an internal version of React (one of 2 versions that now come prebundled with Next and are not the same as latest , hence why react-dom doesn’t have server.edge included in its package.json exports). They actually monkey patch require to override where React is resolved from, based on whether the route is from app or pages. We’re trying to do the same but there’re so many edge cases.
