sanity-io / get-it Goto Github PK

url needs to be validated. Currently it does not, and can result in weird errors like protocol mismatch and similar.

Describe the bug

When using @sanity/client, that uses get-it under the hood, in a clean React Native Expo app no issues are found when using the standard metro configuration. However when I enable unstable_enablePackageExports in the Metro config I'm getting the following error in get-it:

attempted to import the Node standard library module "http". It failed because the native React runtime does not include the Node standard library.

When that setting is enabled get-it somehow forgets to specify the correct runtime?

To Reproduce

Steps to reproduce the behavior:

1. Create a new clean React Native app using Expo.
2. Implement a @sanity/client request.
3. Set unstable_enablePackageExports to true
4. See error

Which versions of Sanity are you using?

Latest

What operating system are you using?

React Native on the latest version of iOS.

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

10.5.0
v20.12.0

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Using a curated preset maintained by

Sanity: The Composable Content Cloud

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• chore(deps): update peter-evans/create-pull-request digest to c5a7806
• chore(deps): update dependency @types/bun to ^1.1.5
• chore(deps): lock file maintenance
• 🔐 Create all pending approval PRs at once 🔐

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency happy-dom to v13
• chore(deps): update dependency happy-dom to v14

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The following fails with Uncaught Error: "/some/endpoint" is not a valid URL:

const request = getIt([jsonResponse()])

request('/some/endpoint') 

Is there any way configure get-it to allow both relative urls and absolute urls?

The Node.js compatibility mode in Deno is removed. The CI tests need to be rewritten to use the new npm: protocol.

Just had deployments starting to crash on vercel after get-it versions for sanity packages were bumped to 8.10 from 8.0.11
I confirmed the break to be in this version by overriding just get-it back to 8.0.11.
Here's the stack trace from the function failure:

TypeError: Right-hand side of 'instanceof' is not an object
    at (../../node_modules/.pnpm/[email protected]/node_modules/get-it/dist/index.browser.js:185:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/get-it/dist/index.browser.js:283:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/get-it/dist/index.browser.js:67:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/get-it/dist/index.browser.js:33:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/get-it/dist/middleware.browser.js:255:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/rxjs/dist/cjs/internal/Observable.js:41:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/rxjs/dist/cjs/internal/Observable.js:35:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/rxjs/dist/cjs/internal/util/errorContext.js:22:0)
    at (../../node_modules/.pnpm/[email protected]/node_modules/rxjs/dist/cjs/internal/Observable.js:26:0)
    at (../../node_modules/.pnpm/@[email protected]/node_modules/@sanity/client/dist/index.browser.js:812:0)

Remove the workspaces property from package.json:

Now, it causes the following warning:
warning Workspaces can only be enabled in private projects.

Hey there!

I belong to an open source security research community, and a member (@ranjit-git) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

The module is required by @sanity/client

Using npm 6.4.1 and Brunch 2.10.17.
Npm compiles the module creating two folders 'lib' and 'lib-node'. However, main entry file index.js points just to './lib-node'

module.exports = require('./lib-node')

This causes module to fail in browser context, where only '/lib' is bundled. However, everything works just fine when manually changed to:

module.exports = require('./lib')

Is this a problem with module or more probably with bundler?

Now that TC39 has landed on an API for aborting ongoing activities, it would be nice to make the promise middleware switch to this pattern. Not all browsers currently support this, so it would probably need a "polyfill".

https://dom.spec.whatwg.org/#aborting-ongoing-activities

The debug middleware tries to use the error in onError, but if an earlier handler has "handled" the error, it'll be null and thus fail.

With the middleware architecture in place, it shouldn't be too difficult to add support for mocking responses. That would be a nice addition that would ease testing in a lot of scenarios, in a way that would work in both browsers and on the server.

Sometimes, all you care about is the response body. For instance, if you are using the httpErrors-middleware, errors are handled "for you", and thus you don't need access to the status code. So it would be great to have a... resolveWithBody-option (name suggestions are welcome) that only resolves the promise with the response body. This reads much nicer with async/await and friends:

const projects = await request({ url: '/v1/projects' })

// vs

const projects = (await request({ url: '/v1/projects' })).body

It'd be nice to have a middleware that could limit the number of response size.
If a content-length is received, that could be used, otherwise just count bytes from the stream.

Don't think we could get this working with the XHR adapter, but should work in Node, and possibly a future fetch adapter (now that streams are implemented/on the way).

There is a bug in the implementation of the error handling.

When an error is encountered (for instance, in the case of a network error or a timeout), the way we wanted to handle retries is to "catch" the error and signal to the requester that it has been handled by simply not returning the error.

The issue is that if no error is returned, the response channel is published to instead.

We need to figure out a way for middleware to be able to say "I've got this, but the request isn't done yet". There aren't currently any other middlewares that utilitize the error capturing, so perhaps we could just leave it up to the middleware to publish a message on the response channel if it wants to somehow trigger the response. Need to think on this some more.