🚀 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