ESM isn't published correctly about next-sanity HOT 7 CLOSED

Thanks for your report @dburles! We don't have a dual package hazard concern in this package, so we opted for 2. 😄

from next-sanity.

Looks great, thanks!

from next-sanity.

🎉 This issue has been resolved in version 1.0.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from next-sanity.

I am receiving this error in Typescript when attempting to import the client:

// lib/sanity/index.ts
import { createClient } from 'next-sanity'
...

$ tsc --noEmit --strict --incremental false

lib/sanity/index.ts:1:30 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("next-sanity")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '***/package.json'.

1 import { createClient } from "next-sanity"
                               ~~~~~~~~~~~~~


Found 1 error in lib/sanity/index.ts:1

This is on [email protected]

It seems the issue stems from moduleResolution: "Node16" in the tsconfig.json, however we need this to leverage the "exports" field in package.json for other imports. We have the "esModuleInterop" set to true in our tsconfig.json and I also tried "allowSyntheticDefaultImports" to no avail

Edit: I'm going to leave this here, but it seems the larger issue is the strange behavior with setting "Node16" as the resolution mode. This thread is a bit over my head: microsoft/TypeScript#49083 but it seems this particular method of module resolution is not to be used frivolously. We are going to work around the reasons we needed that import method as it likely implies issues with the modules that needed it.

Followup again: I don't know if we can actually refactor the places that require "Node16" module resolution at this time. This is used to leverage the "exports" field of package.json in some internal packages. This could be an error on our end.

I can confirm at least for our use case, just slapping a // @ts-expect-error above the import allows it to work fine with "moduleResolution": "Node16" in tsconfig.json... so, not sure what the issue is exactly. we are going to try this out for now since continuing to us the Node16 resolution is a lot simpler in other areas of our codebase currently.

from next-sanity.

To further add to the confusion, this error is apparently not there in our netlify deploy which causes it to fail since I used a //@ts-expect-error:

4:25:17 PM: $ yarn build
4:25:17 PM: yarn run v1.22.19
4:25:17 PM: $ next build
4:25:17 PM: info  - Linting and checking validity of types...
4:25:19 PM: Failed to compile.
4:25:19 PM: 
4:25:19 PM: ./lib/sanity/index.ts:2:1
4:25:19 PM: Type error: Unused '@ts-expect-error' directive.
4:25:19 PM: > 2 | // @ts-expect-error
4:25:19 PM:     | ^
4:25:19 PM:   3 | import { createClient } from "next-sanity"
4:25:19 PM:   4 | import createImageUrlBuilder from "@sanity/image-url"
4:25:19 PM:   5 | import { config } from "./config"

unsure if this is some dependency difference or what.. I don't know how to run the same command that NextJS is outside of the build command

from next-sanity.

I think this is still an issue with this library, I believe the reason it seemed to "resolve" was because when NextJS builds it apparently forces "moduleResolution": "node" according to the issue I referenced in the one below.

vercel/next.js#44095

from next-sanity.

This problem should now be solved in v4: https://github.com/sanity-io/next-sanity/releases/tag/v4.0.0 🙇

from next-sanity.