Running Wrangler locally, I'm told that my version is out of date, and that I should run: ``` npm in

Running Wrangler locally, I'm told that my version is out of date, and that I should run:

npm install --save-dev wrangler@4`

npm install --save-dev wrangler@4`

However this brings the following error:

npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name "4`" of package "wrangler@4`": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name "4`" of package "wrangler@4`": Tags may not have any characters that encodeURIComponent encodes.

MMitya Running Wrangler locally, I'm told that my version is out of date, and that I sh...

Isaac McFadyen•3/18/25, 4:42 PM

You've got a trailing backtick there.

MityaOP•3/18/25, 4:44 PM

Oh god...

MityaOP•3/18/25, 4:44 PM

It's one of those days

MityaOP•3/18/25, 4:44 PM

Sorry to have wasted your time!

Isaac McFadyen•3/18/25, 4:46 PM

No problem

MityaOP•3/18/25, 4:49 PM

One more. Having updated to Wrangler 4, it tells me to change

node_compat

node_compat

nodejs_compat

nodejs_compat

. Should I do this not only in my

dev.toml

dev.toml

but also

wrangler.toml

wrangler.toml

i.e. the TOML for the production version? Does production always use the latest Wrangler?

MityaOP•3/18/25, 5:10 PM

I'm not sure what I'm doing wrong here but since updating my (global) Wrangler to @4, my Worker won't run locally. It advises me to add

node_compat

node_compat

. But a previous message told me to change

node_compat

node_compat

nodejs_compat

nodejs_compat

for use with v.4, which I did. What am I doing wrong?

MityaOP•3/18/25, 5:14 PM

I don't have it installed in my project - I just use a global one. Let me see if uninstalling the global Wrangler and installing project-level Wrangler fixes it. But just to be clear, with v4, it should be

nodejs_compat

nodejs_compat

, not

node_compat

node_compat

, right?

MityaOP•3/18/25, 5:16 PM

OK now I have project-level Wrangler 4. When I run the worker it throws a tonne of errors about Node compatibility and tells me to add

nodejs_compat

nodejs_compat

to my config, which is already there.

MityaOP•3/18/25, 5:18 PM

Although ironically, at the start of the log output, it says

"Unexpected fields found in top-level field: "nodejs_compat"

So I have messages telling me both to add

nodejs_compat

nodejs_compat

and also that

nodejs_compat

nodejs_compat

is invalid.

MityaOP•3/18/25, 5:19 PM

Oh.......

MityaOP•3/18/25, 5:21 PM

Thanks, that's fixed it! Really appreciate your help.

Could I just clarify one more thing. Wrangler is a dev dependency. But the config changes I'm making are for both dev and live. So how do I control/do I need to worry about which version of Wrangler runs in production?

MMitya Thanks, that's fixed it! Really appreciate your help. Could I just clarify one ...

Hard@Work•3/18/25, 5:24 PM

Wrangler shouldn't be running in production? Wrangler is used for development/deployment, but once deployed, Wrangler doesn't touch anything

MityaOP•3/18/25, 5:29 PM

Right, thanks, I think I thought Wrangler ran everywhere.

MityaOP•3/18/25, 5:30 PM

I assumed production used the same environment I had locally, in the same way that developing locally with PHP involves something like Apache, which is also on the live server.

MMitya I assumed production used the same environment I had locally, in the same way th...

Hard@Work•3/18/25, 6:17 PM

Sort of? Wrangler, under the hood, calls into Miniflare, which runs Workers in

workerd

workerd

workerd

workerd

does run in production, but the goal is for you to never need to care which version of

workerd

workerd

is running

nikiv.dev•3/18/25, 10:05 PM

does workers with wrangler support

Buffer

Buffer

James•3/18/25, 10:05 PM

yes

James•3/18/25, 10:05 PM

if you enable

nodejs_compat

nodejs_compat

nikiv.dev•3/18/25, 10:06 PM

nikiv.dev•3/18/25, 10:06 PM

how to get rid of this error, i installed types

nikiv.dev•3/18/25, 10:06 PM

https://github.com/nikitavoloboev/api-ts-hono

nikiv.dev•3/18/25, 10:07 PM

oh ok

nikiv.dev•3/18/25, 10:07 PM

i think its this

nikiv.dev•3/18/25, 10:10 PM

https://developers.cloudflare.com/changelog/2025-03-17-importable-env/ im confused

nikiv.dev•3/18/25, 10:10 PM

i can do this, but where to put the env

iano•3/19/25, 4:14 PM

Wrangler rewrites the request URL being sent to localhost into the custom domain which is set in wrangler.jsonc. Is that expected? It is very surprising to me?

iano•3/19/25, 4:15 PM

(So for example if I curl http://localhost:8787/ with a console.log in the fetch the fetch sees a request to url custom-domain.com even though its running locally)

jonasb•3/19/25, 8:19 PM

Hey

Now when wrangler@4 generates all the types, does anyone have guidance as to how to build libraries that depend on e.g. D1Database? For https://github.com/jonasb/d1-sql-tag I'm using

@cloudflare/workers-types

@cloudflare/workers-types

, but get incompabilities when e.g. upgrading wrangler

GitHub

GitHub - jonasb/d1-sql-tag: A template literal for working with Clo...

A template literal for working with Cloudflare D1 database. - jonasb/d1-sql-tag

MSP2.Leaks•3/20/25, 12:26 PM

Who pinged me

Ppenalosa If you're using `@cloudflare/workers-types`, make sure you're using the `/experi...

echoes221•3/20/25, 3:00 PM

I've noticed that the types generated by wrangler 4.2.0 break on import when using Env as it extends cloudflare.env in the namespace, on 4.0.0 this is fine with no extension. Was this an accidental breaking change? When I say break, I mean that the values don't resolve to the namespace correctly after typegen.

Ppenalosa Could you give an example of how it's broken for you?

echoes221•3/20/25, 5:03 PM

Sure, here is 4.0.0 in the first image, I generally read from Env type where I need it. In 4.2.0 its this

interface Env extends Cloudflare.Env {}

interface Env extends Cloudflare.Env {}

. On further inspection, its when there's a durable object namespace in the types, it doesn't resolve (I'd removed the types to keep it short for this example and it worked). But it's completely fine if the type isn't extended

Ppenalosa We've changed how that file is generated, but it shouldn't cause any breakage in...

echoes221•3/20/25, 5:21 PM

It's the fact that types are no longer found in the rest of the codebase if extending from Cloudflare.Env AND if there is a durable object in there that imports (e.g.

    ORGANISATION_PERFORMANCE_REPORT: DurableObjectNamespace<import("./workers/app").organisationPerformanceReportDO>;

    ORGANISATION_PERFORMANCE_REPORT: DurableObjectNamespace<import("./workers/app").organisationPerformanceReportDO>;

).
You're unable to jump to the typedef, and typescript/IDE throws up errors as they cannot be resolved. Its not possible to cmd + click into the type any longer. I'm using Typescript v5.7.3

Ppenalosa We've changed how that file is generated, but it shouldn't cause any breakage in...

echoes221•3/20/25, 5:26 PM

Easier with a vid to show

Ddan I can't seem to get the new process.env flag to work...I have this in my wrangle...

telliks•3/21/25, 12:30 PM

Did you manage to figure this one out? I'm also having a difficult time getting this to work (locally and deployed)

telliks•3/21/25, 12:34 PM

My expectation might be wrong here. If I set the nodejs_compat_populate_process_envnodejs_compat_populate_process_env compatibility flag with a compatibility date of "2025-03-17", should the env vars defined in my .dev.vars.dev.vars be populated in

process.env

process.env

when running locally?

Ttelliks My expectation might be wrong here. If I set the `nodejs_compat_populate_process...

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

Created a brand new most basic worker and it works as expected. It must be some other incompatibility in my react-router-7 + vite setup then.

Ttelliks Created a brand new most basic worker and it works as expected. It must be some ...

dan•3/21/25, 2:37 PM

I think it's an issue with the vite plugin, I was trying to do it in the agents starter, but when i go to a normal wrangler setup (with 02-28 compat date) it works fine

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

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_.

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

yeah it's probably overwriting it

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:cryptoAssertionError: depsOptimizer is required in dev mode for node:crypto.

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

Running Wrangler locally, I'm told that my version is out of date, and that I should run: ``` npm in

Similar Threads

Similar Threads

Similar Threads