[@sanity/client] running a script with Bun gets the process hanged.

[raulfdm]

If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.

Describe the bug

Running a simple script using the @sanity/client with bun gets the process hanging forever. This doesn't work with tsx.

To Reproduce

Steps to reproduce the behavior:

1. Access this repository https://github.com/devraul/bun-sanity-process-hang
2. Clone it
3. Follow the README instructions
4. See error

Expected behavior

Works with bun without problems

Screenshots

CleanShot.2024-04-10.at.07.03.28.mp4

Which versions of Sanity are you using?

Run sanity versions in the terminal and copy-paste the result here.

What operating system are you using?

"@sanity/client": "6.15.11"

Which versions of Node.js / npm are you running?

❯ bun --revision  
1.1.3+2615dc742

Additional context

Since this is an integration problem, I opened the same problem in Bun. Maybe they need to fix something in their side:
oven-sh/bun#10138

[bjoerge]

Interesting. I got it working in an earlier version of bun (v1.0.17 to be specific), but seeing the same behavior as you when switching to bun v1.1.3)

[raulfdm]

Interesting take @bjoerge . I tested each version and it stopped working on v1.1.0. I'll add this comment there

[bjoerge]

Looks like it could be related to this: oven-sh/bun#7260

[stipsan]

Hi, we tried adding bun conditions in https://github.com/sanity-io/client/releases/tag/v6.15.12 that redirected bun to use the node version of get-it, which uses node:http and node:https under the hood as transport instead of global.fetch.

It created different problems:

• https://github.com/sanity-io/get-it/blob/1c17809502af0fffdeaefd1b19d87d69c98c34e6/src/request/node-request.ts#L198-L199
• https://github.com/sanity-io/client/actions/runs/8647489271/job/23709097678

Surprisingly, changing the bun import conditions to point to the transport that uses fetch appears to solve it:

• ac37787
• https://github.com/sanity-io/client/actions/runs/8648445067/job/23712318406

It's surprising because the assumption has been that bun has used the worker condition until now and always used fetch under the hood.

Here's the basic e2e test we're using:
https://github.com/sanity-io/client/blob/main/runtimes/bun/client.fetch.test.js

The CI tests on Bun 1.1.3, and I've also run the same test locally with Bun 1.1.3 and it works there too.

Give https://github.com/sanity-io/client/releases/tag/v6.15.13 and tell us if that works for you 🙌

[stipsan]

Checking the test rig, it started happening last week:
https://github.com/sanity-io/client-runtimes-compatibility/actions/runs/8516205488/job/23324913908

• @sanity/[email protected]
• [email protected]

Last passing test: https://github.com/sanity-io/client-runtimes-compatibility/actions/runs/8502608803/job/23287010458

• @sanity/[email protected]
• 1.0.36

Based on this, and the error on the CLI that started happening with Bun 1.1.0 seems to be it started using the node version of get-it and @sanity/client indeed.

Here's how you can check what transport is in use:

import {unstable__adapter, unstable__environment} from '@sanity/client'
import {adapter, environment} from 'get-it'

console.log({unstable__adapter, unstable__environment, adapter, environment})

In bun prior to 1.1.0 adapter reports fetch, afterwards it started using node 🤔

In any case that shouldn't be a problem anymore as we now tell Bun exactly what version to use ☺️

[bjoerge]

Closing as it should be fixed as of @sanity/[email protected]

[raulfdm]

Really nice. Thank you for fixing this 🙌