Open Jackenmen opened 4 months ago
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.
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
).
👍🏻 same issue here
You should put .dev.vars.example
to your repository. I think that's enough
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?).
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?
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
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 withwrangler 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 thewrangler.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 :smile:) to thewrangler.toml
file.Suggested solution
I think that the
wrangler.toml
should probably get a newsecrets
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