🚀 Feature Request: Allow to include secrets in wrangler's automatically generated type definitions

[Jackenmen]

Describe the solution

Problem

Currently, there is no way to let wrangler know about secrets so that it can include them in the automatically generated type definitions (wrangler types command).

Tried solutions

I can specify regular env vars in [vars] but when doing so with a secret, it becomes problematic later. For example, trying to set such var's value with wrangler secret put after deployment results in an error saying that the variable is already set and I have to delete all of those encrypted variables first.

I'm pretty sure this is not the intended way of doing things and prevents wrangler.toml from being the full source-of-truth which is its purpose (as documented). Cloudflare's Web UI even tells you to update the wrangler.toml file after updating the env vars with encrypted values, though it just suggests adding <empty textbox> (I had 4 secrets so it actually was a textbox with 4 newlines 😄) to the wrangler.toml file.

Suggested solution

I think that the wrangler.toml should probably get a new secrets array specifically for specifying variables that are encrypted. Technically, it could make sense to allow specifying whether the variable should be encrypted directly in the [vars] table but this would likely be problematic as variable values are not limited to text values (see docs).

Additional context

I asked about this earlier this week on Cloudflare Developers Discord and was asked (by @ Skye-31) to make an issue:
https://discord.com/channels/595317990191398933/799437470004412476/1234495956259704984

[DaniFoldi]

Hi @Jackenmen,

Happy to report that there was a recent change which allows wrangler types to pick up secrets as type string from your .dev.vars file 🎉

If you want to automate it, you can use wrangler secret list, transform that and save it as .dev.vars with any value, and then run type generation.

[Jackenmen]

Hmm, I didn't know that wrangler types picks up variables from .dev.vars.

Sadly, I don't think this solves my issue since the .dev.vars file is not something that should be put in the version control (it's even automatically added to .gitignore in wrangler-generated projects) and therefore doesn't serve as source-of-truth for the Worker configuration. If someone clones my repo and tries running wrangler types, the auto-generated Env interface would be different from what it is supposed to be simply because they didn't create a .dev.vars file with specific variables set (the opposite is also true if one includes some additional env vars in .dev.vars).

[yawnt]

👍🏻 same issue here

[aliyome]

You should put .dev.vars.example to your repository. I think that's enough

[Jackenmen]

That still requires that you create the .dev.vars file on clone (probably in CI or when a new user / contributor clones the repo), it might just make it slightly easier since you could presumably just cp .dev.vars.example .dev.vars to at least declare some (non-sense) values for the variables and therefore have wrangler types do the right thing. I feel like this is the type of thing that build tools should be abstracting for you so that you don't have to do anything special, if you're just doing typical things (and I don't think that having and using secrets in workers is something rare?).
I think it is important for wrangler types to work on clone because the generated types are necessary for type checking to succeed (without the file, some Env attributes are going to be missing) and building shouldn't be requiring credentials (yes, they can be fake but why should they be needed in the first place?).

[Codex-]

I also encountered this cryptic behaviour, at first I was manually declaring an interface in addition to the generated one to give some typeness to the secrets being declared and then only by chance discovered that the typegen uses .dev.vars

I failed to find any documentation stating the inclusion of this file in the typegen.

It's a bit unintuitive, as the template / project generation builds a project that explicitly git ignores the .dev.vars file but then for type safety on the env it when generating the types .dev.vars is used?

• type-generation finding secrets (source)
• getVarsForDev hard coding .dev.vars (source)

I like the idea of being able to forward declare available secrets in wrangler, but I suppose since there is a disjoin between deploying secrets and wrangler.toml this may become unintuitive for other reasons.

Could we consider having a way to specify what files to read from for available secrets instead on the types command? This way we could simply target a .dev.vars.template or similar without committing the .dev.vars files to get consistent typegen. This also helps prevent developers from accidentally committing secrets

As a semi-related note, I also found it a bit difficult to understand from the documentation how secrets were treated. I understood it as "you declare the secrets as empty variables and the secrets are provided at runtime" but this isn't correct, and if you have a variable + secret of the same name, the variable takes precedence. Probably a me problem, would be nice to be explicitly clear about this behaviour in the documentation though

[kevinsimper]

@Codex- I would be a fan of defining them in wrangler.jsonc since it would be explicit and other programs that read wrangler.json would also be able to understand all keys to run the application

[TimStepanovAtBrandBoosting]

Could we perhaps get an update on this? This would be a huge QOL improvement.

Our current workaround is to just include the .dev.vars file in the git repository with dummy values for the secrets. This is ugly and prevents using them for local development.

[LeonBlade]

Cloudflare's intention behind environment variables is that you should be using the .dev.vars for your local environment variables including secrets. With that in mind, you still need to communicate your secrets across the dev team either way, afterwards running the typegen will generate the proper env variables.

That being said, I'm not sure if there is any downside to having typegen generate these except for in niche situations where you're using local env vars that aren't deployed as secrets in the project yet. However, this alone may be reason not to support something like this.

My understanding of this may be misguided however, so please feel free to correct me if you think I'm wrong. I do think providing a .dev.vars.example file or something equivalent is a good start and you can communicate on how to adjust this for development with the team.