does anyone have any tips for working with `wrangler types` in monorepo packages? I have multiple wo

D

danOP•3/26/25, 8:05 PM

this is really annoying and common in my codebase right now, i'm in a monorepo package that shouldn't depend on a worker in the monorepo so i have no idea how to resolve these types

S

shay•3/26/25, 8:23 PM

how can i debug errors thrown by

wrangler dev

wrangler dev

wrangler dev

wrangler dev like the one below? not sure if it's a vite issue (i'm migrating from remix's classic compiler) but the vite build itself completes successfully (

remix vite:build

remix vite:build

remix vite:build

remix vite:build).

⎔ Starting local server...
✘ [ERROR] service core:user:discohook-site: Uncaught TypeError: d7t is not a function
    at null.<anonymous> (server.js:452:17894)

⎔ Starting local server...
✘ [ERROR] service core:user:discohook-site: Uncaught TypeError: d7t is not a function
    at null.<anonymous> (server.js:452:17894)

⎔ Starting local server...
✘ [ERROR] service core:user:discohook-site: Uncaught TypeError: d7t is not a function
    at null.<anonymous> (server.js:452:17894)

⎔ Starting local server...
✘ [ERROR] service core:user:discohook-site: Uncaught TypeError: d7t is not a function
    at null.<anonymous> (server.js:452:17894)

i'm just not sure where to begin. to my knowledge,

server.js

server.js

server.js

server.js is not a file that has been generated by my build

A

April•3/27/25, 9:06 AM

vc

Ddan does anyone have any tips for working with `wrangler types` in monorepo packages...

D

DaniFoldi•3/27/25, 3:21 PM

yeah my recommendation is to not use workers types, or use it once and then fix it manually

D

DaniFoldi•3/27/25, 3:21 PM

unfortunately there are still many missing features for me to be able to recommend it

D

DaniFoldi•3/27/25, 3:22 PM

manually the way you would override it is to use

DurableObjectNamespace<import('where your DO class is exported').exportname>

DurableObjectNamespace<import('where your DO class is exported').exportname>

DurableObjectNamespace<import('where your DO class is exported').exportname>

DurableObjectNamespace<import('where your DO class is exported').exportname> or

Service<same import

Service<same import

Service<same import

Service<same import for service bindings

D

danOP•3/27/25, 3:22 PM

right but that breaks dependency chains in some cases

D

danOP•3/27/25, 3:22 PM

or results in cyclical depencies

D

danOP•3/27/25, 3:23 PM

what i'm doing right now which kind of works is manually declaring the interfaces in a standalone package that has no dependencies that can be imported like:

declare global {
  namespace Dependencies {
    type RecipeParser = Service<RecipeParserWorker>;
    interface RecipeParserWorker extends WorkerEntrypoint<unknown> {
      /**
       * Main entry point that handles recipe parsing requests
       */
      fetch(request: Request): Promise<Response>;
      parseRecipeFromUrl(recipeUrl: string): Promise<Response>;
      modifyRecipe(input: { recipe: RecipeSchema; instructions: string }): Promise<Response>;
      /**
       * Parse recipe using a two-phase approach:
       * 1. Try fetch first (faster, less resource intensive)
       * 2. Fall back to puppeteer if fetch doesn't yield good results
       */
    }

    class RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

declare global {
  namespace Dependencies {
    type RecipeParser = Service<RecipeParserWorker>;
    interface RecipeParserWorker extends WorkerEntrypoint<unknown> {
      /**
       * Main entry point that handles recipe parsing requests
       */
      fetch(request: Request): Promise<Response>;
      parseRecipeFromUrl(recipeUrl: string): Promise<Response>;
      modifyRecipe(input: { recipe: RecipeSchema; instructions: string }): Promise<Response>;
      /**
       * Parse recipe using a two-phase approach:
       * 1. Try fetch first (faster, less resource intensive)
       * 2. Fall back to puppeteer if fetch doesn't yield good results
       */
    }

    class RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

declare global {
  namespace Dependencies {
    type RecipeParser = Service<RecipeParserWorker>;
    interface RecipeParserWorker extends WorkerEntrypoint<unknown> {
      /**
       * Main entry point that handles recipe parsing requests
       */
      fetch(request: Request): Promise<Response>;
      parseRecipeFromUrl(recipeUrl: string): Promise<Response>;
      modifyRecipe(input: { recipe: RecipeSchema; instructions: string }): Promise<Response>;
      /**
       * Parse recipe using a two-phase approach:
       * 1. Try fetch first (faster, less resource intensive)
       * 2. Fall back to puppeteer if fetch doesn't yield good results
       */
    }

    class RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

declare global {
  namespace Dependencies {
    type RecipeParser = Service<RecipeParserWorker>;
    interface RecipeParserWorker extends WorkerEntrypoint<unknown> {
      /**
       * Main entry point that handles recipe parsing requests
       */
      fetch(request: Request): Promise<Response>;
      parseRecipeFromUrl(recipeUrl: string): Promise<Response>;
      modifyRecipe(input: { recipe: RecipeSchema; instructions: string }): Promise<Response>;
      /**
       * Parse recipe using a two-phase approach:
       * 1. Try fetch first (faster, less resource intensive)
       * 2. Fall back to puppeteer if fetch doesn't yield good results
       */
    }

    class RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

D

danOP•3/27/25, 3:23 PM

RecipeParser

RecipeParser

RecipeParser

RecipeParser works fine, i'm struggling with DO declarations though, like that namespace doesn't actually work (it doesnt' give errors, but

test()

test()

test()

test() doesn't appear on the type when consuming it

D

DaniFoldi•3/27/25, 3:23 PM

yeah you can do this, or you can pre-generate the type and publish that to a repository and import that

Ddan `RecipeParser` works fine, i'm struggling with DO declarations though, like that...

D

DaniFoldi•3/27/25, 3:24 PM

for that you need to use the import from cloudflare:workers

D

danOP•3/27/25, 3:26 PM

which import? I am using DurableObject from there

D

danOP•3/27/25, 3:26 PM

the tsconfig of this dependencies package has

"types": ["@cloudflare/workers-types"]

"types": ["@cloudflare/workers-types"]

"types": ["@cloudflare/workers-types"]

"types": ["@cloudflare/workers-types"]

D

danOP•3/27/25, 3:33 PM

ah i just got it

D

danOP•3/27/25, 3:33 PM

    type RecipeAgent = Rpc.DurableObjectBranded & {
      test: () => Promise<void>;
    };

    type RecipeAgent = Rpc.DurableObjectBranded & {
      test: () => Promise<void>;
    };

    type RecipeAgent = Rpc.DurableObjectBranded & {
      test: () => Promise<void>;
    };

    type RecipeAgent = Rpc.DurableObjectBranded & {
      test: () => Promise<void>;
    };

D

danOP•3/27/25, 3:33 PM

this seems to work

D

danOP•3/27/25, 3:38 PM

ah ok... there are mulitple DO exports

DDaniFoldi for that you need to use the import from cloudflare:workers

D

danOP•3/27/25, 3:38 PM

i undertand this now

D

danOP•3/27/25, 3:38 PM

import type { DurableObject } from 'cloudflare:workers';

declare global {
  namespace Dependencies {
    interface RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

import type { DurableObject } from 'cloudflare:workers';

declare global {
  namespace Dependencies {
    interface RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

import type { DurableObject } from 'cloudflare:workers';

declare global {
  namespace Dependencies {
    interface RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

import type { DurableObject } from 'cloudflare:workers';

declare global {
  namespace Dependencies {
    interface RecipeAgent extends DurableObject<unknown> {
      test: () => Promise<void>;
    }

    type RecipeAgentNamespace = DurableObjectNamespace<RecipeAgent>;
  }
}

works

D

danOP•3/27/25, 3:38 PM

was a conflict with the one from worker types

D

DaniFoldi•3/27/25, 3:40 PM

yeah the default one doesn't have RPC types, for backwards compatibility reasons

D

DaniFoldi•3/27/25, 3:41 PM

and you need the entrypoint to be there at runtime becase RPC reasons

D

DaniFoldi•3/27/25, 3:41 PM

so the tsconfig types entry isn't enough for that

D

danOP•3/27/25, 3:43 PM

copy, wasn't aware there was a distinction

D

danOP•3/27/25, 3:43 PM

i think this is the best thing to do now, and maybe write a bash script to replace instances of these bindings with the types from my dependencies package after running

wrangler types

wrangler types

D

danOP•3/27/25, 3:44 PM

instance methods on service bindings or DOs don't really change frequently so it's not a big deal

D

danOP•3/27/25, 3:44 PM

but this is definitely a really awkward aspect of developing with workers

Ddan but this is definitely a really awkward aspect of developing with workers

D

DaniFoldi•3/27/25, 5:30 PM

Agreed

J

JacobMGEvans•3/28/25, 2:12 AM

I am about to get REAL into Durable Objects, be pepared for an onslaught of stupid questions

V

Vlady•3/29/25, 1:10 AM

Y'all, my build used to work with wrangler 3, but not with v4. Why is wrangler expecting the config to be in the build folder when I build my app and run

wrangler dev

wrangler dev

wrangler dev

wrangler dev?

There is a deploy configuration at ".wrangler/deploy/config.json".

  But the redirected configuration path it points to, "build/server/wrangler.json", does not exist.

There is a deploy configuration at ".wrangler/deploy/config.json".

  But the redirected configuration path it points to, "build/server/wrangler.json", does not exist.

There is a deploy configuration at ".wrangler/deploy/config.json".

  But the redirected configuration path it points to, "build/server/wrangler.json", does not exist.

There is a deploy configuration at ".wrangler/deploy/config.json".

  But the redirected configuration path it points to, "build/server/wrangler.json", does not exist.

wrangler.toml

compatibility_date = "2025-02-10"
compatibility_flags = ["nodejs_compat"]
assets = { directory = "./build/client" }
main = './src/entry.worker.ts'

compatibility_date = "2025-02-10"
compatibility_flags = ["nodejs_compat"]
assets = { directory = "./build/client" }
main = './src/entry.worker.ts'

compatibility_date = "2025-02-10"
compatibility_flags = ["nodejs_compat"]
assets = { directory = "./build/client" }
main = './src/entry.worker.ts'

compatibility_date = "2025-02-10"
compatibility_flags = ["nodejs_compat"]
assets = { directory = "./build/client" }
main = './src/entry.worker.ts'

I'm running my

yarn preview

yarn preview

yarn preview

yarn preview script, here's how it's defined in package.json

 "preview": "yarn build && wrangler dev",
 "build": "react-router build",

 "preview": "yarn build && wrangler dev",
 "build": "react-router build",

 "preview": "yarn build && wrangler dev",
 "build": "react-router build",

 "preview": "yarn build && wrangler dev",
 "build": "react-router build",

What am I doing wrong here? I want to test if my React Router 7 build works locally.

V

Vlady•3/29/25, 1:14 AM

I'm following the official template and the error is the same if I match the config and commands 1 to 1 https://github.com/cloudflare/templates/blob/staging/react-router-starter-template/wrangler.json

V

Vlady•3/29/25, 1:19 AM

I deleted this and it started working, not sure what generated it in the first place

T

thomasgauvin•3/30/25, 2:20 AM

How do you run a Worker project, within another Worker project? Wrangler seems to hang on detecting multiple wrangler.jsonc files, need to manually indicate which to use but it doesn't seem to be a parameter? https://developers.cloudflare.com/workers/wrangler/commands/#dev

Tthomasgauvin How do you run a Worker project, within another Worker project? Wrangler seems t...

M

MattIPv4•3/30/25, 3:49 AM

Try the

--config

--config

--config

--config flag? It’s documented in other places as doing what you want here

T

thomasgauvin•3/30/25, 3:51 AM

Yep, that ended up working, thanks @MattIPv4

M

MattIPv4•3/30/25, 3:51 AM

And file an issue for updating the err to include that

T

thomasgauvin•3/30/25, 3:52 AM

Yeah, need to explain what's wrong + how to fix it in the error log, otherwise it's spam in the channel (like me rn)

M

MattIPv4•3/30/25, 3:52 AM

And if you want, an issue for the docs to make it clearer that’s a global flag :nod:

A

Alejandro Mery•3/31/25, 7:11 PM

hi, when trying to deploy from a dev container, I get a link for oauth but when approving it I'm told "No redirect uri set!" and later wrangler fails with "timed out waiting for authorization code"

any idea how to get this to work again?

A

Alejandro Mery•3/31/25, 7:13 PM

pnpm wrangler whoami

pnpm wrangler whoami

pnpm wrangler whoami

pnpm wrangler whoami has the same problem

no redirect uri set

A

Alejandro Mery•3/31/25, 7:34 PM

it used to work by opening a tunnel for

TCP6:[::1]:8976

TCP6:[::1]:8976

TCP6:[::1]:8976

TCP6:[::1]:8976 but now without a redirect url the whole thing breaks down

M

mau•4/2/25, 5:37 PM

Hey folks, I'm running into an issue with the WARP client.

Whenever I have WARP running, my fetch calls (in wrangler) break due to certificate errors. I’ve installed the Cloudflare certificate that WARP uses and tried setting the NODE_EXTRA_CA_CERTS environment variable to point to the .pem file (as suggested in the Workers SDK), but it's not working.

Is there something else I need to do to make wrangler trust the WARP cert? Or does WARP interfere in a way that can't be resolved just by trusting the CA?

Appreciate any help—thanks!

T

Tpf•4/3/25, 7:51 AM

Hi,

During dev cycles the worker I'm responsible for needs to have access to live (remote) KV data so I've always run

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote. This works fine.

Now I've added a durable object to the project and found that when running

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote the DO is evicted (including persistent storage) every few seconds and on every save of a file. This is a known issue (https://github.com/cloudflare/workers-sdk/issues/2700) that Cloudflare closed as 'not planned'. I see that using

wrangler dev --local

wrangler dev --local

wrangler dev --local

wrangler dev --local works alright for DO.

How does one develop a worker using both DO and remote KV? What am I missing? Is this just not something people are doing? Any advice much appreciated!

GitHub

🐛 BUG: wrangler dev Durable object storage resets after 10 secon...

Which Cloudflare product(s) does this pertain to? Workers/Other What version of Wrangler are you using? 2.9.1 What operating system are you using? Windows Describe the Bug If you use wrangler dev t...

M

Marcel Overdijk•4/4/25, 6:42 AM

Hi, I'm trying to migrating from @cloudflare/workers-types to wrangler types but it does not seem to work....
I've started with an empty template from

npm create cloudflare@latest -- --type openapi

npm create cloudflare@latest -- --type openapi

npm create cloudflare@latest -- --type openapi

npm create cloudflare@latest -- --type openapi
and then followed the migration steps here: https://developers.cloudflare.com/workers/languages/typescript/
so mainly:

npm uninstall @cloudflare/workers-types
npx wrangler types
Make sure your tsconfig.json includes the generated types
{
"compilerOptions": {
"types": ["worker-configuration.d.ts"]
}
}

M

Marcel Overdijk•4/4/25, 6:44 AM

but the tsconfig file already complains about:
Cannot find type definition file for 'worker-configuration.d.ts'.
The file is in the program because:
Entry point of type library 'worker-configuration.d.ts' specified in compilerOptions

and that file is genereated in my root folder as per the instructions.
and the

Env

Env

interface is not recognized in other parts of the code...

MMarcel Overdijk but the tsconfig file already complains about: Cannot find type definition file ...

J

James•4/4/25, 12:28 PM

Is your repo public so we can take a look? Or can you share the generated file?

M

matthewlsessions•4/5/25, 4:36 PM

Just an FYI, the React on Workers with Assets template no longer serves with assets: https://github.com/cloudflare/workers-sdk/blob/d4c11710fd36286be8587379d659e19e91778777/packages/create-cloudflare/templates/react/workers/ts/worker/index.ts#L10

It conflicts with what is found in the docs: https://developers.cloudflare.com/workers/frameworks/framework-guides/react/

J

James•4/5/25, 5:15 PM

That looks to be expected - the Worker will only be run after Assets, and if one isn't hit. Do you have a reproducible example issue?

JJames That looks to be expected - the Worker will only be run _after_ Assets, and if o...

M

matthewlsessions•4/5/25, 6:56 PM

Right out of the box if you create the app through the CLI for workers with assets, then deploy the Worker handler is never invoked. See this screenshot as it should be return the Hello World json response:

does anyone have any tips for working with `wrangler types` in monorepo packages? I have multiple wo

Similar Threads

Similar Threads

Similar Threads