I can't repro 🤔

Admittedly, I'm using vitest - but I don't imagine it makes any difference

A number of wrangler's tests do use it themselves too - if it was an issue for everyone, it would have been noticed long ago

If you can make a minimal reproducible example, I'll happily try it out

If I make the worker run local, it works just fine. But this one runs with

local: false

and is the one that hangs

All my runs on this project are through github actions and it's a public repo so you should be able to see it all too

That's the only difference between my testing code that works in a different project, and this one

Yup, that's the issue. The moment I make

local: true

the test exits instantly

The

ts
worker = await unstable_dev('src/index.ts', { local: false, experimental: { disableExperimentalWarning: true } });

vs

ts
worker = await unstable_dev('src/index.ts', { local: true, experimental: { forceLocal: true, disableExperimentalWarning: true } });

if I want to make my own

JavaScriptRewriter

, is this the proper way of fetching plaintext?

typescript
fetch('https://example.com/x.js',
    {
      method: 'GET',
      headers: {
        'Accept-Encoding': 'identity'
      }
    }
  );

Oh, interesting - definitely make an issue for that

You could also try experimental local to run it in a more similar environment to production than regular local can provide

when using ES module workers, is there some way I can monkey patch my env variables into a global process.env?

You could throw them on globalThis but it's really not recommended

@kian ah amazing, I'll give that a try. I'm trying to use a library that's written to run in node, and I want to see if I can coax it into working. obviously passing an API_KEY all the way into its depths is going to be a struggle

Is API_KEY a secret or in

[vars]

?

I've just chucked it in vars for development, not sure of the distinction

is a secret something set in the dashboard?

@kian I should be using

.dev.vars

instead of putting it in

wrangler.dev.toml

?

they're both shoved into

env

right?

are there any particular reasons why this isn't recommended? what if I need to write code that has to run in both a node environment (that I don't control) with secrets provided through process.env.. and also in my remix app in my worker?

It isn’t recommended because CF can sometimes switch environments without fully rebooting your Worker. If you are always running from the env object, that won’t be an issue. If you are pulling from the global scope, you might suddenly be trying to reach a binding that no longer exists

This is why the env object exists in the module syntax, rather than globals in the service Worker syntax

but if I copy the variables from the env object to

globalThis

in my fetch function that should be fine right?

a request can't move environment mid request can it?

I'm specifically trying to work with the newly announced https://defer.run

it does some magic where you have background task functions that are wrapped to proxy to their service through an API

No, but a Worker may be processing multiple requests at once, and may be reused multiple times

hmm, also the library I'm using tries to get the environment variable at import time so maybe I'm screwed