Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support .env via miniflare #190

Closed
marbiano opened this issue Jan 4, 2022 · 9 comments · Fixed by #879 or #882
Closed

Support .env via miniflare #190

marbiano opened this issue Jan 4, 2022 · 9 comments · Fixed by #879 or #882
Assignees
@petebacondarwin
Labels
enhancement New feature or request

Comments

@marbiano
Copy link

marbiano commented Jan 4, 2022 •
edited
Loading

Miniflare automatically supports picking up the content of .env files. This is a very common practice in Node environments and is especially handy when building projects with frameworks like Remix that support multiple deployment targets. I think it would be beneficial and very handy to add support for this on wrangler2.
@threepointone
Copy link
Contributor

Yeah, maybe. I'm thinking deeply about vars/secrets lately. It'll likely involve dotenv, or something similar. I'll assign this to myself atm.

@threepointone threepointone self-assigned this Jan 5, 2022
@Electroid Electroid added the enhancement New feature or request label Jan 5, 2022
@threepointone threepointone mentioned this issue Jan 7, 2022
Closed
27 tasks
@anonrig
Copy link
Member

anonrig commented Jan 13, 2022

This became an issue for me. I'm trying to convert a Remix application running on Vercel to Cloudflare Pages and had to connect to Discord to understand why this does not work (which made me comment this for future reference)

"node -r dotenv/config node_modules/.bin/wrangler pages dev ./public --watch ./build ./styles"

@petebacondarwin petebacondarwin moved this to Non-blocking in workers-sdk Jan 25, 2022
@threepointone threepointone mentioned this issue Jan 25, 2022
Merged
@threepointone threepointone removed their assignment Jan 29, 2022
@petebacondarwin petebacondarwin added this to the Wrangler 2.0 milestone Feb 1, 2022
@BasixKOR
Copy link

BasixKOR commented Feb 7, 2022

Would you mind if I make a PR implementing this? I think passing envPath the detected .env file with the --env option to override to Miniflare would be enough, but it seems like you have a different idea in mind.

@isaac-mcfadyen isaac-mcfadyen mentioned this issue Feb 12, 2022
Closed
@connerdavis47 connerdavis47 mentioned this issue Feb 18, 2022
Closed
@motiejunas
Copy link

Yeah, maybe. I'm thinking deeply about vars/secrets lately. It'll likely involve dotenv, or something similar. I'll assign this to myself atm.

@threepointone so what is on your mind? Can @BasixKOR move forward with envPath idea?

@threepointone
Copy link
Contributor

We haven't taken a call here yet. It has to apply in both local and edge mode, (and not just pages) and we don't want to create a dependency without understanding it deeply. We may likely go with dotenv, but we just haven't taken a call yet.

@BasixKOR
Copy link

BasixKOR commented Mar 11, 2022 •
edited
Loading

Ah, I haven't given a thought about edge mode. My thought was that since Miniflare already supports importing a .env file we could pass the path of the file, but this wouldn't work on edge mode.

My implementation (which I'm using right now) is here: https://github.com/BasixKOR/wrangler2/tree/dotenv

@petebacondarwin petebacondarwin mentioned this issue Apr 27, 2022
Closed
@petebacondarwin
Copy link
Contributor

Perhaps we could add support for two variants of .env files: wrangler.env and runtime.env?

The former would be provided to Wrangler (i.e. for bundling in publish and dev, and for specifying things like CLOUDFLARE_API_TOKEN for many of the commands that need to access the Cloudflare API).
The latter would be provided to the runtime as variable bindings, which should satisfy the scenario of specifying secrets in local mode.

@petebacondarwin petebacondarwin self-assigned this Apr 27, 2022
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 3, 2022
@petebacondarwin
feat: read vars overrides from a local file for wrangler dev
31eddb3 
The `vars` bindings can be specified in the `wrangler.toml` configuration file.
But "secret" `vars` are usually only provided at the server -
either by creating them in the Dashboard UI, or using the `wrangler secret` command.

It is useful during development, to provide these types of variable locally.
When running `wrangler dev` we will look for a file called `.dev.vars`, situated
next to the `wrangler.toml` file (or in the current working directory if there is no
`wrangler.toml`). Any values in this file, formatted like a `dotenv` file, will add to
or override `vars` bindings provided in the `wrangler.toml`.

Related to cloudflare#190
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 3, 2022
@petebacondarwin
feat: read vars overrides from a local file for wrangler dev
5d9c3ac 
The `vars` bindings can be specified in the `wrangler.toml` configuration file.
But "secret" `vars` are usually only provided at the server -
either by creating them in the Dashboard UI, or using the `wrangler secret` command.

It is useful during development, to provide these types of variable locally.
When running `wrangler dev` we will look for a file called `.dev.vars`, situated
next to the `wrangler.toml` file (or in the current working directory if there is no
`wrangler.toml`). Any values in this file, formatted like a `dotenv` file, will add to
or override `vars` bindings provided in the `wrangler.toml`.

Related to cloudflare#190
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 3, 2022
@petebacondarwin
feat: read vars overrides from a local file for wrangler dev
85843b7 
The `vars` bindings can be specified in the `wrangler.toml` configuration file.
But "secret" `vars` are usually only provided at the server -
either by creating them in the Dashboard UI, or using the `wrangler secret` command.

It is useful during development, to provide these types of variable locally.
When running `wrangler dev` we will look for a file called `.dev.vars`, situated
next to the `wrangler.toml` file (or in the current working directory if there is no
`wrangler.toml`). Any values in this file, formatted like a `dotenv` file, will add to
or override `vars` bindings provided in the `wrangler.toml`.

Related to cloudflare#190
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 3, 2022
@petebacondarwin
feat: add support for reading build time env variables from a .env …
16555d2 
…file

This change will automatically load up a `.env` file, if found, and apply its
values to the current environment. An example would be to provide a specific
CLOUDFLARE_ACCOUNT_ID value.

Related to cloudflare#190
@petebacondarwin petebacondarwin mentioned this issue May 3, 2022
Merged
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 3, 2022
@petebacondarwin
feat: add support for reading build time env variables from a .env …
e27122b 
…file

This change will automatically load up a `.env` file, if found, and apply its
values to the current environment. An example would be to provide a specific
CLOUDFLARE_ACCOUNT_ID value.

Related to cloudflare#190
@petebacondarwin petebacondarwin mentioned this issue May 3, 2022
Merged
This was linked to pull requests May 3, 2022
Locally overriding vars in wrangler dev #879
Merged
feat: add support for reading build time env variables from a .env file #882
Merged
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 4, 2022
@petebacondarwin
feat: add support for reading build time env variables from a .env …
d12fddd 
…file

This change will automatically load up a `.env` file, if found, and apply its
values to the current environment. An example would be to provide a specific
CLOUDFLARE_ACCOUNT_ID value.

Related to cloudflare#190
@petebacondarwin petebacondarwin moved this from Should-have to In Progress in workers-sdk May 4, 2022
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 4, 2022
@petebacondarwin
feat: add support for reading build time env variables from a .env …
db77991 
…file

This change will automatically load up a `.env` file, if found, and apply its
values to the current environment. An example would be to provide a specific
CLOUDFLARE_ACCOUNT_ID value.

Related to cloudflare#190
petebacondarwin added a commit that referenced this issue May 4, 2022
@petebacondarwin
feat: add support for reading build time env variables from a .env …
1ad7570 
…file (#882)

This change will automatically load up a `.env` file, if found, and apply its
values to the current environment. An example would be to provide a specific
CLOUDFLARE_ACCOUNT_ID value.

Related to #190
Repository owner moved this from In Progress to Done in workers-sdk May 4, 2022
@github-actions github-actions bot mentioned this issue May 4, 2022
Merged
petebacondarwin added a commit to petebacondarwin/wrangler2 that referenced this issue May 4, 2022
@petebacondarwin
feat: read vars overrides from a local file for wrangler dev
8f74ec9 
The `vars` bindings can be specified in the `wrangler.toml` configuration file.
But "secret" `vars` are usually only provided at the server -
either by creating them in the Dashboard UI, or using the `wrangler secret` command.

It is useful during development, to provide these types of variable locally.
When running `wrangler dev` we will look for a file called `.dev.vars`, situated
next to the `wrangler.toml` file (or in the current working directory if there is no
`wrangler.toml`). Any values in this file, formatted like a `dotenv` file, will add to
or override `vars` bindings provided in the `wrangler.toml`.

Related to cloudflare#190
@threepointone
Copy link
Contributor

reopening, waiting on #879 as well

@threepointone threepointone reopened this May 4, 2022
Repository owner moved this from Done to In Progress in workers-sdk May 4, 2022
petebacondarwin added a commit that referenced this issue May 4, 2022
@petebacondarwin
Locally overriding vars in wrangler dev (#879)
f694313 
* test: use `fs` consistently in dev tests

* feat: read `vars` overrides from a local file for `wrangler dev`

The `vars` bindings can be specified in the `wrangler.toml` configuration file.
But "secret" `vars` are usually only provided at the server -
either by creating them in the Dashboard UI, or using the `wrangler secret` command.

It is useful during development, to provide these types of variable locally.
When running `wrangler dev` we will look for a file called `.dev.vars`, situated
next to the `wrangler.toml` file (or in the current working directory if there is no
`wrangler.toml`). Any values in this file, formatted like a `dotenv` file, will add to
or override `vars` bindings provided in the `wrangler.toml`.

Related to #190
Repository owner moved this from In Progress to Done in workers-sdk May 4, 2022
@marbiano
Copy link
Author

marbiano commented May 4, 2022

Thank you, folks!

@luc122c luc122c mentioned this issue Apr 28, 2023
Closed
@dario-piotrowicz dario-piotrowicz mentioned this issue May 22, 2024
Closed
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@petebacondarwin petebacondarwin

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
7 participants
@marbiano @petebacondarwin @threepointone @anonrig @Electroid @BasixKOR @motiejunas