Disable Wrangler caching

[penalosa]

Wrangler's caching behaviour (where it persists interactive user choices like account ID) is helpful from a DX perspective in the common case that a user is following the happy path (choosing an account once at first publish time), but can be confusing in cases where a user strays outside the bounds of that (publishing a worker to multiple accounts, for instance).

In an effort to make this behaviour clearer to users (and to enable future enhancements), I propose removing Wrangler's current caching behaviour in favour of an approach familiar to the JavaScript ecosystem; a wrangler.lock file.

Why is this better?

1. It's made more explicit, and will hopefully make the behaviour of Wrangler clearer to users (since it won't be relying on values from a hidden cache file)
2. It's more shareable; users could commit their wrangler.lock file and a whole team of developers could be sure they were running Wrangler with the same behaviour (as well as having more confidence in their CI pipelines)
3. It's extensible; there are a lot of cases where it would be nice DX for us to store a decision for users, but we currently don't. Specifically, this could be things like autogenerating KV namespace IDs based off a user specified name (and storing the ID in the lock file).

What would this look like?

• Wrangler would continue to support reading the current cached values.
• Going forward, when a new cached value is to be stored, Wrangler will instead generate a wrangler.lock file.
• When reading cached values, Wrangler will first check for the presence of a wrangler.lock file

What would the format be?
JSON(C) is probably the best choice here. Initially, this would be the same format as the current hidden cache file.

How could we version this?
The lock file could include a "wrangler_version": "x.x" field. As the lock file format changes, future Wrangler versions should be able to modify the lock file in place to update to the latest format.

cc @cloudflare/wrangler

[JacobMGEvans]

Your proposal to replace Wrangler's current caching behavior with a wrangler.lock file is a good idea. It would make Wrangler's behavior more explicit, shareable, and extensible. The lock file in JSON format would be easily readable and the versioning field would help with future compatibility. This approach aligns with the JavaScript/TypeScript ecosystem and could lead to improved user experience with Wrangler. I agree with your proposal.

It's important to weigh the benefits and possible drawbacks:

• Increased complexity - The addition of a wrangler.lock file could add an extra layer of complexity for users who are not familiar with configuration files; We keep adding stuff...

• Compatibility issues - If the format of the wrangler.lock file changes in the future, older versions of Wrangler may not be able to read it correctly, leading to compatibility issues; I don't think we would but it creates the possibility.

• Increased file size - The wrangler.lock file could grow in size as more values are added to it, leading to increased disk usage; The cache is more ethereal the lock is more concrete as well.

A possible solution could be to provide users with the option to use the current caching behavior or switch to the wrangler.lock file, depending on their preference.

[IgorMinar]

Have you considered persisting the info in wrangler.toml instead?

Isn't this info primarily just account ID?

I often don't put account ID into my wrangler.toml because I'm too lazy to look it up. If wrangler offered to save the info in the config file for me then I'd happily say yes.

But my suggestion doesn't solves the situation well for a multi-account deployments. For example a scenario where a team has a prod and staging environment stored in separate accounts, and each team member has their own dev environment in their private account.

I however don't believe that the wrangler.lock file supports this scenario well either or does it?