-
Notifications
You must be signed in to change notification settings - Fork 5
Support environments in Worker configs #127
Conversation
commit: |
| test('returns the correct custom-env var when CLOUDFLARE_ENV=custom-env', async () => { | ||
| expect(await getTextResponse()).toEqual('Custom env var'); | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to use vi.stubEnv (https://vitest.dev/api/vi.html#vi-stubenv) here instead of changing process.env in the Vite config. It didn't work though (I think because the Vite config has already run by the time we run the test).
dario-piotrowicz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, I just left some minor comments 🙂
That sounds like a good idea, wrangler does read .env files for config purposes so this would be consistent with that But I don't know if |
This is only for use within the plugin itself though so we would only use it to get the |
yeah that's a good point, yes I would be in favour of calling |
petebacondarwin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with some nits.
595081b to
8b35fbf
Compare
resolves #29
This adds support for the
CLOUDFLARE_ENVenvironment variable to determine the environment that is used in the Worker config.When updating the versions of Wrangler and Miniflare, I had to make changes to the Workflow tests to reflect changes in the implementation. I have also updated all the compatibility dates to the most recent.
Note that the environment variable will not work if provided in a
.envfile. Vite only automatically provides values from.env(prefixed withVITE_) to code rather than config. TheloadEnvfunction (https://vite.dev/guide/api-javascript.html#loadenv) needs to be used to access variables from.envelsewhere (by default this only loads env variables prefixed withVITE_).Do you think we should call
loadEnvin the plugin in so that the value can be read from.envfiles?