🚀Feature request: Allow easy overriding of secrets-store in `.dev.vars`

[medz]

Describe the solution

In the local workers development process, when a worker depends on other workers, and the dependent worker depends on secrets-store secret, this will cause great trouble to the local development process.

When not depending on other workers, we can create an env variable and determine whether it is a string or an Object with a get() method when using it, for example:

/// Bindings.ts
readonly DATABASE_URL: string | SecretsStoreSecret;

/// Using
const databaseUrl = typeof env.DATABASE_URL === "string" ? env.DATABASE_URL : await env.DATABASE_URL.get();

But this is not a panacea. When one of my workers needs to depend on another worker, and the other worker depends on SecretsStoreSecret, problems arise. Even if I declare { "binding": "API", "service": "api-core", "environment": "dev" },, it doesn't work at all. Always appears:

Binding Resource Mode
env.DATABASE_URL Secrets Store Secret loca

And wrangler secrets-store secret is very inconvenient, it needs to be configured once for each worker. The essence of secrets-store is to share secrets between workers.

**Just like Hyperdrive, we can use special variables to override bindings. This can be very useful during development.

Especially when we need to make changes to multiple workers at the same time.**

[penalosa]

Could you expand on your proposed .dev.vars solution? We currently support wrangler secrets-store secret, which allows you to change secrets on a per-worker basis (as .dev.vars would, because that's also per-worker). You can use the --persist argument to Wrangler to make state shared across workers (by providing the same path)—I wonder if that would address the issue?

[medz]

@penalosa Just like when developing hyperdrive locally, you can directly set the local database connection string through the WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_* prefix.

I think secrets-store is also the best, because I am very distressed now. I have three related workers, and I use secrets-store to facilitate the management of some keys.

My compatible code in a single worker is as follows:

type ENV = { xxxxx_KEY: string | {get: () => Promise<string>} }
const key = typeof env.xxxxx_KEY === "string" ? env.xxxxx_KEY : await env.xxxxx_KEY.get();

This is very convenient for local development, but when encountering multiple collaborations, for example:

wrangler dev --cwd /workers/a -c wrangler.jsonc -c ../b/wrangler.jsonc -c ../c/wrangler.jsonc

Need to start a worker, but the configuration of a worker in wrangler.jsonc:

"services": [
  { "binding": "A", "service": "a-worker" },
  { "binding": "B", "service": "b-worker" },
]

Since a and b depend on different secrets-stores, the previous compatible code is no longer available, and child workers are forced to enable local secrets-store binding.

It would be much simpler if it was allowed to override in .dev.vars:
.dev.vars:

SECRETS_STORE_SECTET_xxxxx_KEY=xxx

This allows the bound secrets-store to be directly overwritten during local development, and the local one will be used when the .dev.vars of the dependent worker also has the corresponding configuration.

[NOTE]
The above behavior logic is consistent with the logic of hyperdrive's local development overwriting link string, which is very beneficial for local development.

Now secrets-store uses the wrangler secrets-store secret command to manage the secrets-store for local development, which is very inconvenient and often forgotten. But it is more convenient to manage the keys of the cloudflare platform.

[medz]

Now I have configured more than a dozen different secrets-stores in my account, and they are bound to one or more by different workers. But some workers depend on other workers, and they together form a business logic or workflow. This causes a lot of trouble for using secrets-store locally and starting local development with multiple -c parameters. I can judge by multiple types when developing a single worker without dependencies. Once it comes to worker development that depends on other workers, I must use the wrangler secrets-store secret command to configure keys for multiple dependent workers. Moreover, workers have many repeated dependencies, and configuring secrets-store is much more troublesome than directly writing .dev.vars files, and it is easy to forget. Once a key needs to be updated during development, I need to find all the workers used for local development to configure the local secrets-store command, which is very troublesome.

So I hope to be able to configure the secrets-store for local development directly in .dev.vars, because this will become very convenient for developers during the development process.