Closed markomitranic closed 6 months ago
Hi @markomitranic, we're investigating this issue with our friends at Vercel 🙌 Will keep you posted
Hey @markomitranic, could you try npm i next@canary --save-exact
?
They've pushed a fix to the underlying turbopack build 🙌
@stipsan I had the same issue and following your instructions resolved it.
I can also confirm it seems to work just fine now :) @stipsan I wonder what caused it, its obviously on the turbo end, but also has to be something the studio does that triggered it, quite interesting stuff
There's more information in the related fix in turbo here: https://github.com/vercel/turbo/pull/7959
It's probably related to us shipping Node ESM native support in v3.37.0: https://github.com/sanity-io/sanity/releases/tag/v3.37.0
Before that node in ESM mode would be redirected back to CJS mode by using the CJS ESM re-export pattern, as we had node.import
export conditions for it. In other words in a lot of frameworks, Next.js included, whenever you imported sanity
you always got the CJS code. I'm not sure if that's related but that's the only change we made that could've caused a change to bundler behavior recently 🤷
@stipsan FYI, I bumped to Sanity 3.39.0 and Next 14.2.2 this morning and the issue is no longer present.
Describe the bug
Sanity studio no longer working in development, when running in turbo dev mode. Running a studio, according to the guide within this repository is broken with the following error:
To reproduce, I have used the latest official nextjs bug reproduction project. And only added studio to it, according to the appdir readme of this repository.
To Reproduce
Steps to reproduce the behavior:
npm i
cp .env.dist .env.local
npm run dev
andnpm run dev:turbo
.In other reproductions, for example when using on real projects with plugins and similar, the symptoms vary from not being able to load studio at all, due to 100% timeout rate - to working fine but turning the CPU into a toaster oven.
Expected behavior
The studio should work as it normally does, and as it does without the turbo flag.
I've tried various
next-sanity
andnext
versions, down to 14.0.0 and 7.0.0, and this never seems to work correctly.If using turbo is not yet possible (I'm aware turbo is beta and not all test are passing) perhaps we should write something about this in the readme for this repo, and for the sanity repo, for the time being. It's fairly straightforward when faced with an error like this, but It's been a lot of trouble figuring this out, in cases where it was just consuming our whole CPUs, as we had no idea that studio was the one that was jacking up the
next
process.Screenshots
![Uploading Screenshot 2024-04-14 at 11.53.05.png…]()
Which versions of Sanity are you using?
@sanity/cli (global) 3.37.2 (up to date)
// Only Sanity dependency in the
package.json
."next-sanity": "9.0.2",
What operating system are you using?
macOS Sonoma
14.4.1 (23E224)
Which versions of Node.js / npm are you running?
10.2.4 v20.11.1