fix: emit ESM with .mjs

[stipsan]

Adding type: commonjs in the package json without also updating the file endings used for ESM to mjs broke environments such as NextJS.

See:

• @sanity/ui Module parse failed.  nextjs-blog-cms-sanity-v3#155
• Cannot find module '@sanity/ui' nextjs-blog-cms-sanity-v3#154
• chore(deps): lock file maintenance nextjs-blog-cms-sanity-v3#157
• https://app.renovatebot.com/package-diff?name=@sanity/ui&from=1.0.4&to=1.0.6

Reproduced build outputs: https://vercel.com/sanity-io/nextjs-blog-cms-sanity-v3/4fr81igyWY9wnyLuUY4PcfHtCNGE

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
sanity-ui-workshop	✅ Ready (Inspect)	Visit Preview	Dec 30, 2022 at 10:44PM (UTC)

[mariuslundgard]

Unfortunately this project is not ready for .mjs extensions (or "type": "module") because of the peer dependency on styled-components.

[stipsan]

@mariuslundgard this PR does not add type: module, it adds .mjs to fix said regression.
Not merging this PR means it's impossible to use Studio v3 in Next.js apps without locking @sanity/ui to 1.0.4 or older 😅

[stipsan]

@mariuslundgard Alternatively revert adding type: commonjs: 34f62fe#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519

[mariuslundgard]

Yes, we'll need to revert "type": "commonjs".

[mariuslundgard]

Fwiw, I tested with Next.js before releasing and it worked fine for me. Will do some more testing to evaluate how I got it wrong.

[stipsan]

Yeah it's happened to me multiple times as well, especially while adding ESM to next-sanity. The only surefire way to test that I've found is to do a prerelease on npm and test next dev and next build with that.
Anything involving symlinks or messing around in node_modules can't be trusted 😢

[mariuslundgard]

This means Next.js does not interpret packages the same way Node.js does. We should point this out to the Next.js team, since it potentially hinders Node ESM adoption.

[stipsan]

I'm not sure if that's the case. Adding type: commonjs means only .mjs files may use ESM syntax. The errors we're seeing is correct in that sense.
The problematic Next.js behavior I'm referring to is that it'll sometimes transpile symlinked packages and create a false positive that way, when it should rather consistently fail when defining pkg.type to either commonjs or module.

[mariuslundgard]

I'm adding a change to @sanity/pkg-utils to make the revert possible: sanity-io/pkg-utils#37

[mariuslundgard]

I'm not sure if that's the case. Adding type: commonjs means only .mjs files may use ESM syntax. The errors we're seeing is correct in that sense.

This is from the Node spec, @stipsan:

If the nearest parent package.json lacks a "type" field, or contains "type": "commonjs", .js files are treated as CommonJS.

[mariuslundgard]

Closing this PR in favor of aa51484