Error using $fetch.create using CJS modules. about ofetch HOT 14 CLOSED

@pi0

is there a reason, why the cjs/* import the *,mjs files ?

Would it not be easier, to simply build a cjs version with the following build.config.ts ?

import { defineBuildConfig } from 'unbuild'

export default defineBuildConfig({
  declaration: true,
  rollup: {
    emitCJS: true,
  },
  entries: [
    'src/index',
    'src/node',
    'src/undici'
  ]
})

I believe building it in CJS is the only possible solution afaik, because we cannot load mjs, without being async...

from ofetch.

Same here with es module import...
I'm trying to do this:

import { $fetch } from 'ohmyfetch'

const apiFetch = $fetch.create({ baseURL: '/api' })

And error shown in the nuxt console is the same:

 ERROR  ERROR in utils/fetch.ts:3:25                                                                                                                                                                                                                                            14:54:08
TS2339: Property 'create' does not exist on type '$Fetch'.
    1 | import { $fetch } from 'ohmyfetch'
    2 |
  > 3 | const apiFetch = $fetch.create({ baseURL: '/api' })

from ofetch.

@BrandonlinU I actually got rid of the error by updating the dependency to the latest version. I was on 0.4.8 and updating to 0.4.14 fixed it.

from ofetch.

@jarekcieslak Your solution is correct, your error was because you are using ESM and you don't have the updated version, the create method was introduced in the version 0.4.13, but in my case I am in the version 0.4.14 using CJS modules and because the CJS proxy module does not export a create method Node complains about that.

from ofetch.

@pi0 I am experiencing the same issue in Nuxt.js 2 using ohmyfetch 0.4.15.

ohmyfetch__WEBPACK_IMPORTED_MODULE_3__.$fetch.create is not a function

Edit: I found the reason for the issue and created a PR.

from ofetch.

@P4sca1 Yeah... that will not work. I tried the same way as you, but the CJS proxy use Promises because the ES Module specification says that a module CAN use a top-level await, so you can't be sure that a ES Module does not use Promises, but $fetch.create() is a syncronous method, not a async method just like $fetch() or $fetch.raw(). Try to run your code with my example code and print out the new scoped client: You must see Promise { <pending> } and if you try to use it Node complains about the scoped client is not a function.

from ofetch.

Sorry, bad button.

from ofetch.

@BrandonlinU I tried the change locally by editing the files in node_modules and it works fine for me.
Maybe because I am not directly using the created fetch instance but only on the click of a button.

Edit: The change worked for me, because I never actually used the created fetch instance on the server. I am using nuxt.js and only used the instance on the client where the ESM build is used.

A workaround for Node.js would be to await the call to $fetch.create when using the CJS Bundle.

from ofetch.

As a workaround you can use ESM version:

const { createFetch } = await import('ohmyfetch')

from ofetch.

How would that work?

I tried the following in my nuxt 2 plugin without success:

const { $fetch } = await import('ohmyfetch')
const $api = $fetch.create(defaults)

const { fetch, Headers, createFetch } = await import('ohmyfetch')
const $api = createFetch({ fetch, Headers, defaults })

from ofetch.

Another issue is that FetchError is not exported in CJS. Would it be possible to have the same exports for both CJS and ESM?

from ofetch.

I also experienced the same problems, tried the same solutions, only to finally detect, that by adding the create to cjs will end up as a promise later...

As I was in a typescript environment, it was even more difficult to find this, as I was using ohmyfetch on client side with esm, and on server side with cjs...

Client and Server both used the same code for the create...

Is there any other possible solution?

from ofetch.

I'm still getting this in 1.0.0 and I'm not sure what the issue is

from ofetch.

Possibly same as #198, to which a fix PR has been submitted.

from ofetch.