I think it's an issue with the vite plugin, I was trying to do it in the agents starter, but when i

Ddan I think it's an issue with the vite plugin, I was trying to do it in the agents ...

T

telliks•3/21/25, 2:54 PM

I wonder if vite is not clearing the

process.env

process.env

when running client side. What I noticed now is that I can access

process.env

process.env

vars in react-router loaders that run server-side, but those vars are not defined on

process.env

process.env

for client-side code, even when prepended with

VITE_PUBLIC_

VITE_PUBLIC_

.

D

danOP•3/21/25, 3:07 PM

yeah it's probably overwriting it

E

echoes221•3/21/25, 8:17 PM

I've been attempting to get

@cloudflare/vite-plugin

@cloudflare/vite-plugin

working and running up against a bit of a wall when starting the app (with RRv7). I'm getting a

"AssertionError: depsOptimizer is required in dev mode"

"AssertionError: depsOptimizer is required in dev mode"

|

[plugin:vite:import-analysis] depsOptimizer is required in dev mode

[plugin:vite:import-analysis] depsOptimizer is required in dev mode

error, which appears to come up when the source is a node module? I extended the the assertion for the source that's failing and it looks like its

AssertionError: depsOptimizer is required in dev mode for node:crypto

AssertionError: depsOptimizer is required in dev mode for node:crypto

.

Is there any compatibility issue with node modules with the vite plugin?

P

Paul•3/24/25, 5:39 AM

I'm considering using Cloudflare Pages + Durable Objects with SQL on a new project, with Sveltekit as the framework, and came across the issues described here:

https://github.com/sveltejs/kit/issues/1712

Long story short, the durable object can't be in the same wrangler project as the sveltekit project (at least according to the most recent comment in this issue)

Is this still the case? The workaround looks pretty iffy - a monorepo with 2 wrangler projects, one for the DO and one for Sveltekit, then named bindings linking the 2 and some bodges to proxy requests between the projects when testing locally.

I note there's a Beta feature "Frameworks" - does this have the same issue with not allowing DO's to be hosted in the same wrangler project?

A

awful•3/25/25, 12:54 AM

I was in the process of updating pages to 0.0.16 when I got an error: Cannot find module '/Users/username/.npm/_npx/769b1efcb4c28da2/node_modules/pages/node_modules/coffee-script'

I have tried to do npm install -g coffee-script as well as npm install -g coffeescript. I have also tried to uninstall wrangler.

I am on an Intel MacBook Pro and using Sonoma 14.6.1.

J

James•3/25/25, 2:09 AM

What is the

pages

pages

npm package and why would you need it? That’s over a decade old and for AngularJS and almost certainly won’t work in Workers

JJames What is the `pages` npm package and why would you need it? That’s over a decade ...

A

awful•3/25/25, 2:38 AM

https://developers.cloudflare.com/workers/wrangler/commands/#pages

J

James•3/25/25, 2:38 AM

That’s a wrangler command - you don’t need to install

pages

pages

from npm.

npx wrangler pages dev

npx wrangler pages dev

for example will run a local dev server for Cloudflare Pages

A

awful•3/25/25, 2:39 AM

Thanks I probably forgot to type wrangler

A

adt•3/25/25, 12:51 PM

Hey All! Im trying to run an Astro SSR app with cloudflare. I'm having type conflicts with the wrangler generated types when calling client side web apis from a client side script... For example, calling fetch from a client side script will reference the workerd fetch type and not the web api. Is there a work around or am i missing something?

C

Cibulka•3/26/25, 5:36 PM

Why don't my static files load

C

Cibulka•3/26/25, 5:36 PM

all of them just give 404 errors

V

veeque•3/26/25, 5:59 PM

running

wrangler d1 execute --help

wrangler d1 execute --help

I see the option for

-y

-y

. Is there the opposite?

-n

-n

? I need to have the

.sql

.sql

file for D1 be created (to get its name) by running

wrangler d1 execute id-development -e development --command ' ' --local

wrangler d1 execute id-development -e development --command ' ' --local

which will result in an error and I don't think spamming Cloudflare with random stuff is something I should do

V

veeque•3/26/25, 6:10 PM

When the command fails it asks:

Would you like to report this error to Cloudflare? Wrangler's output and the error details will be shared with the Wrangler team to help us diagnose and fix the issue. (Y/n)

Would you like to report this error to Cloudflare? Wrangler's output and the error details will be shared with the Wrangler team to help us diagnose and fix the issue. (Y/n)

Would you like to report this error to Cloudflare? Wrangler's output and the error details will be shared with the Wrangler team to help us diagnose and fix the issue. (Y/n)

Would you like to report this error to Cloudflare? Wrangler's output and the error details will be shared with the Wrangler team to help us diagnose and fix the issue. (Y/n)

, and using

-y

-y

would say yes every time, also

| yes n

| yes n

is not an option

V

veeque•3/26/25, 6:49 PM

ohh that one's good, ty

D

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

does anyone have any tips for working with

wrangler types

wrangler types

in monorepo packages? I have multiple workers that can bind to one another (as well as DOs) but I'm not sure how to get a typed reference to

workers/my-agent

workers/my-agent

from

apps/api

apps/api

without

apps/api

apps/api

importing from

workers

workers

(which I don't want)

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

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

).

⎔ 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

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>

or

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

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

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"]

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>;
    };

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