wrangler publish has inconsistent behavior

[xortive]

Steps to reproduce

• wrangler generate <name here> Use a name that isn't used currently, as wrangler will overwrite an existing one.
• set a name, route, zone_id, account_id, and private=true in wrangler.toml.
• run wrangler publish
  output says worker was successfully published but it only appears in the editor UI and isn't actually published anywhere. this is issue Unclear messaging of wrangler publish #357.
• run wrangler publish --release
  output says worker was successfully published. You can view it at <route>. which is True.
• make a change to your worker so it returns something else
• run wrangler publish
  output says worker was successfully published but in reality, the script running at route was also updated without passing in the --release flag. This is confusing.

[kristianfreeman]

I find the publish versus publish --release confusing, too. I think the context is that we can think of a workers.dev subdomain as a sort of staging environment, and releasing the app to a zone is where that terminology comes together. I'm imagining that if we were to switch the commands, and have something like publish --staging publish to workers.dev, while publish goes to a zone, I would find that set of commands confusing too.

Thinking about #385, I do wonder if it might make sense to just become very explicit about zoned deploy targets. Publishing with now will default to a random now.sh domain (basically analogous to our wrangler publish), and you can pick a "target" to deploy to (functionally, they're aliases) using now --target $target (where $target might be staging or production).

Makes me wonder if it would make sense to deprecate the --release subcommand in favor of just using the --env flag from #385. That way, it always defaults to workers.dev, and a zoned deploy is wrangler publish --env production (or staging, etc)

[EverlastingBugstopper]

I would also quite like that, I find the wrangler publish -> zoneless and wrangler publish --release -> zoned to be quite confusing. Especially if people's primary worker use case is zoneless and they really are doing releases every time they publish. We would definitely need to discuss if we are trying to keep this reverse compatible and what that would mean.

[gabbifish]

I think introducing --env instead of --release might still lead to confusion between zoneless and zoned workers; honestly, running publish where the env file is read by default and people specify either zoneless or zoneful configs there would be simpler and more explicit. This would possibly change #385 but I think this is worth it in the name of maximal clarity and cohesive development experience between zoned and zoneless workers.

[ashleymichal]

we think this will be mostly addressed by the work being done in the Environments milestone; however, there may still be some surprising behavior if users deviate from best practices. Should reassess after Environments is released.