@mrbbot Do queue consumers receive messages in the `vitest` environment? I have a worker that's bot

V

Vlady•4/29/23, 7:38 PM

Hi y'all, is it possible to interactively debug a durable object? When I add breakpoints in my tests, the VSCode debugger goes into the stub instead of the actual object.

This is how I'm writing tests

describe('Cart durable object', () => {
  let context: GraphqlContext
  let config: AppConfig
  let cart: Durable.Object

  beforeAll(async () => {
    context = createTestContext()
    config = context.config

    const id = context.bindings.Cart.newUniqueId()
    cart = context.bindings.Cart.get(id)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add', config })

    const resp = await cart.fetch(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
      }),
    })

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let config: AppConfig
  let cart: Durable.Object

  beforeAll(async () => {
    context = createTestContext()
    config = context.config

    const id = context.bindings.Cart.newUniqueId()
    cart = context.bindings.Cart.get(id)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add', config })

    const resp = await cart.fetch(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
      }),
    })

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let config: AppConfig
  let cart: Durable.Object

  beforeAll(async () => {
    context = createTestContext()
    config = context.config

    const id = context.bindings.Cart.newUniqueId()
    cart = context.bindings.Cart.get(id)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add', config })

    const resp = await cart.fetch(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
      }),
    })

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let config: AppConfig
  let cart: Durable.Object

  beforeAll(async () => {
    context = createTestContext()
    config = context.config

    const id = context.bindings.Cart.newUniqueId()
    cart = context.bindings.Cart.get(id)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add', config })

    const resp = await cart.fetch(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
      }),
    })

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

V

Vlady•4/29/23, 8:36 PM

So, it turns out to properly test the object, I had to manually instantiate it like this. Otherwise it would swallow errors and logs and that's difficult to debug.

describe('Cart durable object', () => {
  let context: GraphqlContext
  let cart: Cart

  beforeAll(async () => {
    context = createTestContext()
    const id = context.bindings.Cart.newUniqueId()
    const state = await getMiniflareDurableObjectState(id as any)
    cart = new Cart(state, context.bindings)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add' })

    const req = new Request(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
        quantity: 1,
      }),
    })

    const resp = await cart.fetch(req)

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let cart: Cart

  beforeAll(async () => {
    context = createTestContext()
    const id = context.bindings.Cart.newUniqueId()
    const state = await getMiniflareDurableObjectState(id as any)
    cart = new Cart(state, context.bindings)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add' })

    const req = new Request(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
        quantity: 1,
      }),
    })

    const resp = await cart.fetch(req)

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let cart: Cart

  beforeAll(async () => {
    context = createTestContext()
    const id = context.bindings.Cart.newUniqueId()
    const state = await getMiniflareDurableObjectState(id as any)
    cart = new Cart(state, context.bindings)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add' })

    const req = new Request(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
        quantity: 1,
      }),
    })

    const resp = await cart.fetch(req)

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

describe('Cart durable object', () => {
  let context: GraphqlContext
  let cart: Cart

  beforeAll(async () => {
    context = createTestContext()
    const id = context.bindings.Cart.newUniqueId()
    const state = await getMiniflareDurableObjectState(id as any)
    cart = new Cart(state, context.bindings)
  })

  test('add item', async () => {
    const url = createCartDurableObjectUrl({ path: 'add' })

    const req = new Request(url, {
      method: 'POST',
      body: JSON.stringify({
        itemId: 'World of Warcraft: The Burning Crusade',
        quantity: 1,
      }),
    })

    const resp = await cart.fetch(req)

    const items: CartItem[] = await resp.json()
    expect(items).toEqual([
      {
        id: 'World of Warcraft: The Burning Crusade',
        name: 'World of Warcraft: The Burning Crusade',
        price: {
          amount: 1,
          currency: Currency.Gbp,
        },
        quantity: 1,
      },
    ])
  })
})

TTravisFrank @mrbbot Do queue consumers receive messages in the `vitest` environment? I have...

M

MrBBot•5/2/23, 9:07 PM

Hey!

Apologies for the delayed response. It looks like there is a bug here. Miniflare doesn't realise it needs to register event listeners for your Worker when running tests with Queue consumers set up. As a temporary workaround, you can define an empty Durable Object in your Worker, and add it to your

vitest.config.ts

vitest.config.ts

vitest.config.ts

vitest.config.ts's

environmentOptions

environmentOptions

environmentOptions

environmentOptions. See https://gist.github.com/mrbbot/a1d5ddc5d7fd2878d58cf5f8215e9a3a for an example.

Gist

Vitest Queue Consumers Fix

Vitest Queue Consumers Fix. GitHub Gist: instantly share code, notes, and snippets.

V

vvo•5/4/23, 9:36 AM

I am curious about a code example I saw in the miniflare blog post: https://blog.cloudflare.com/miniflare/
It contains:

export async function increment(namespace, key) {
  // method
}

export default {
  async fetch(request, env, ctx) {
    // handler which uses increment
  },
};

export async function increment(namespace, key) {
  // method
}

export default {
  async fetch(request, env, ctx) {
    // handler which uses increment
  },
};

export async function increment(namespace, key) {
  // method
}

export default {
  async fetch(request, env, ctx) {
    // handler which uses increment
  },
};

export async function increment(namespace, key) {
  // method
}

export default {
  async fetch(request, env, ctx) {
    // handler which uses increment
  },
};

Is it common to expose internal methods like increment and test them separately in Jest? I thought it would be always "better" to only test the handler.
The official doc doesn't contain such examples, mostly curious here

Vvvo 👋 I am curious about a code example I saw in the miniflare blog post: https://b...

D

DaniFoldi•5/4/23, 9:42 AM

Yep, unit tests usually cover single components, and mock everything else to isolate issues to individual parts. The examples don't contain such tests as they (should) work normally with or without the miniflare environment. If you find something that breaks because of the miniflare environment, drop a message here or feel free to open an issue on GitHub

DDaniFoldi Yep, unit tests usually cover single components, and mock everything else to iso...

V

vvo•5/4/23, 9:45 AM

I was gonna use miniflare-jest to test my worker by making fetch requests to it, as seen in https://miniflare.dev/testing/jest#writing-and-running-tests. I guess we could call theses "integration tests". Can you confirm this is the right way (I guess so, given the doc).

C

CalBoy•5/4/23, 2:04 PM

Has anyone had any trouble with miniflare + module workers + the JS API?

I'm trying to migrate a servier-worker to a module worker for various reasons and I can't get miniflare to let me debug the module worker. Whenever I run the NodeJS debugger and put debug statements in it's almost like miniflare isn't even loading my worker.

I start miniflare via

    let mf = new miniflare.Miniflare({
        wranglerConfigPath: true,
        upstream: testingDetails.url,
        modules: true,
        cache: false,
        kvNamespaces: ["CONFIG"]
    });

    let mf = new miniflare.Miniflare({
        wranglerConfigPath: true,
        upstream: testingDetails.url,
        modules: true,
        cache: false,
        kvNamespaces: ["CONFIG"]
    });

    let mf = new miniflare.Miniflare({
        wranglerConfigPath: true,
        upstream: testingDetails.url,
        modules: true,
        cache: false,
        kvNamespaces: ["CONFIG"]
    });

    let mf = new miniflare.Miniflare({
        wranglerConfigPath: true,
        upstream: testingDetails.url,
        modules: true,
        cache: false,
        kvNamespaces: ["CONFIG"]
    });

C

CalBoy•5/4/23, 2:32 PM

Ah ha! Setting

scriptPath

scriptPath

scriptPath

scriptPath manually appears to have fixed it which is weird. I've then had to correctly setup

--experimental-vm-modules

--experimental-vm-modules

--experimental-vm-modules

--experimental-vm-modules now we're getting closer.

I'm not hitting issues with

Some functionality, such as asynchronous I/O (fetch, Cache API, KV).....

Some functionality, such as asynchronous I/O (fetch, Cache API, KV).....

Some functionality, such as asynchronous I/O (fetch, Cache API, KV).....

Some functionality, such as asynchronous I/O (fetch, Cache API, KV)..... but its erroring during the request context.

CCalBoy Ah ha! Setting `scriptPath` manually appears to have fixed it which is weird. I'...

M

MrBBot•5/4/23, 3:38 PM

Hey!

Not ideal, but as a temporary workaround you can disable that restriction locally with https://miniflare.dev/core/standards#global-functionality-limits. What's the full stack trace of that error?

MMrBBot Hey! 👋 Not ideal, but as a temporary workaround you can disable that restrictio...

C

CalBoy•5/4/23, 3:41 PM

Thats what I ended up doing, well for a bit. It was getting stuck in KV lookups. I then ended up hitting issues with an

input instanceof Request

input instanceof Request

input instanceof Request

input instanceof Request check during the dispatchFetch handling. Which led me to - https://github.com/cloudflare/miniflare/issues/454

I ended up pinning a bunch of my deps. Removing package-lock and doing a fresh

npm i

npm i

npm i

npm i and it fixed a whole heap of things.

GitHub

Failed to parse URL from [object Object] · Issue #454 · cloudflare/...

I tried to upgrade from 2.10.0 to 2.11.0 and failed with the issue: [mf:err] POST /api/endpoint/1: TypeError: Failed to parse URL from [object Object] at new Request (/Users/Maxim/project/node_modu...

C

CalBoy•5/4/23, 3:41 PM

And after doing that it all appears stable.

C

CalBoy•5/4/23, 3:42 PM

Well apart from having to set the scriptPath. Not entirely sure why that isn't coming from package.json anymore

CCalBoy Well apart from having to set the scriptPath. Not entirely sure why that isn't c...

M

MrBBot•5/4/23, 5:14 PM

Have you got the

packagePath: true

packagePath: true

packagePath: true

packagePath: true option set?

MMrBBot Have you got the `packagePath: true` option set?

C

CalBoy•5/5/23, 8:29 AM

Yup and had a

module

module

module

module set in package.json doing what was required for that above issue fixed it tho

I

ItHurtsWhenIPvp•5/13/23, 6:40 AM

Has anyone tried wrapping miniflare in their own package? Im looking to build a custom miniflare to interact with workers and our internal tooling. We're mostly wanting the local reproduction without giving the ability to publish themselves within the enterprise.

I

ItHurtsWhenIPvp•5/18/23, 8:25 AM

I may just be really tired today, but wasn't miniflare able to run typescript locally without a build step? May have been dreaming too.

S

sathoro•5/18/23, 7:16 PM

I ran into another thing that miniflare does not fail on but real workers do fail:

const myBlob = await response.blob();

await env.BUCKET.put(blobId, myBlob); // must use myBlob.stream()

const myBlob = await response.blob();

await env.BUCKET.put(blobId, myBlob); // must use myBlob.stream()

const myBlob = await response.blob();

await env.BUCKET.put(blobId, myBlob); // must use myBlob.stream()

const myBlob = await response.blob();

await env.BUCKET.put(blobId, myBlob); // must use myBlob.stream()

Ssathoro I ran into another thing that miniflare does not fail on but real workers do fai...

A

Adam•5/18/23, 7:22 PM

Can you file this in the Miniflare repo? https://github.com/cloudflare/miniflare/issues/new

AAdam Can you file this in the Miniflare repo? https://github.com/cloudflare/miniflare...

S

sathoro•5/18/23, 7:25 PM

https://github.com/cloudflare/miniflare/issues/584 done

RRph Is it possible to somehow enable support for `eval` in miniflare?

M

MrBBot•5/24/23, 8:42 AM

Hey!

This isn't possible right now unfortunately. What's your use case?

RRph I wanted to build myself something akin to a hybrid between jupyter and codepen ...

M

MrBBot•5/24/23, 8:45 AM

Interesting... you might want to look into the Chrome DevTools protocol. Miniflare supports starting an inspector server, which you can then send WebSocket messages to for evaluating code in the Miniflare context.

B

Ben-xD•5/27/23, 6:59 AM

Is wrangler3/miniflare3 planning to add support for breakpoints/debugging?

U

Unsmart•5/27/23, 7:38 PM

Seems to be there

https://github.com/cloudflare/miniflare/blob/6bace6b464e1458ac3621d14d639750455299853/packages/miniflare/src/api.ts#L111

GitHub

miniflare/api.ts at 6bace6b464e1458ac3621d14d639750455299853 · clou...

Fully-local simulator for Cloudflare Workers. Contribute to cloudflare/miniflare development by creating an account on GitHub.

miniflare/api.ts at 6bace6b464e1458ac3621d14d639750455299853 · clou...

W

Walshy•5/27/23, 7:45 PM

in miniflare 3 it may have been removed/renamed

W

Walshy•5/27/23, 7:45 PM

but I'd recommend just using Wrangler, Miniflare hasn't been the recommended way to do local development/testing for a few years now

Nndls i might just be daft, but doing local dev with cloudflare is not easy, and the d...

A

Adam•5/28/23, 9:21 PM

PM for Workers here

Thanks for the feedback. Updating and enhancing local documentation is in the works. Hopefully consolidating everything with Wrangler will reduce the need to figure out questions like - is this Miniflare or Wrangler. Sorry for the problems so far though. If I can help at all feel free to ping me directly.

Also, we are aware of the sveltekit issue and are talking through solutions there.

E

ernest•5/30/23, 6:16 AM

Openly thinking, are there an glaring reason why Miniflare would not be suitable for any production loads other than the fact that it's a watered down version/emulation/simulation of the full CF stack?

The novel use case I am envisioning is a hybrid-offline mode type of setup where we can fallback to a localised miniflare when outages happen?

W

Walshy•5/30/23, 7:45 AM

The fact it's an emulation and not 100% true to prod

Though if Workers are down, so is a lot of CF these days haha so there'd be much bigger problems than just Workers not firing

You can run workerd which is the Workers runtime locally but again, I wouldn't worry about this scenario.

E

ernest•5/31/23, 7:04 AM

Less on workers/cf being down, but more localised problems like the ISP and power outages. Context is we're building some restaurant operation tools and was exploring using miniflare as a local/offline backend to work with in localhost until connectivity is restored

Z

zegevlier•5/31/23, 7:16 AM

Workerd will be a better bet in that case. It's designed to be ran locally

H

Hello, I’m Allie!•5/31/23, 8:00 AM

I would note too that

workerd

workerd

has some eccentricities from it being tailored to the CF platform, so while it works fine(mostly) for local dev, and you can use it for production loads, I would probably recommend adding a service-worker or equivalent to your tool code so that it can keep itself running, rather than trying to wrangler

workerd

workerd

into working locally.

S

Samy•6/1/23, 11:38 AM

Is miniflare still maintained as the recommended way to develop unit tests for workers?
We are working on adapting a work with durable objects to use the new WebSocket hibernation API, and it doesn't look like miniflare supports it, but mainly it looks like there is not much activity on the miniflare repo and no issue/PR about supporting this new API.

S

Samy•6/1/23, 11:39 AM

workerd seems to be the main way to run workers locally now, but it doesn't offer the same controls as miniflare (ex: trigger an alarm, access DO storage, restart the worker, etc).

SSamy workerd seems to be the main way to run workers locally now, but it doesn't offe...

H

Hello, I’m Allie!•6/1/23, 11:44 AM

There are three systems for developing/testing Workers locally:
workerd - the Workers Runtime
miniflare - provides Mocks and Compat stuff
wrangler - CLI and pixelcf

API interface.
All of these parts interoperate to produce a local development/testing environment
With the release of wrangler 3, everything should run through wrangler, rather than Miniflare directly.

S

Samy•6/1/23, 12:42 PM

Yes I'm getting that, but in my case it's more about the unit tests case, so using the JS API of Miniflare to run it and call different functions on it to inspect its state.
When running the worker for development, we use wrangler.

SSamy Yes I'm getting that, but in my case it's more about the unit tests case, so usi...

D

DaniFoldi•6/1/23, 12:56 PM

for the time being, i'd stick to your current setup (which I'm assuming is

vitest-environment-miniflare

vitest-environment-miniflare

vitest-environment-miniflare

vitest-environment-miniflare, or maybe

jest-environment-miniflare

jest-environment-miniflare

jest-environment-miniflare

jest-environment-miniflare), and there should be a new variant that supports v3 soontm

@mrbbot Do queue consumers receive messages in the `vitest` environment? I have a worker that's bot

Similar Threads

Similar Threads

Similar Threads