Wrangler: Zoneless support

[nickbalestra]

As suggested by @xtuc , I'm opening an issues to start the conversation around supporting zone-less Workers in Wrangler.

What are your thoughts in this direction?

[xtuc]

We haven't discussed about it, but here's what I have in mind:

• Deploying a zoneless Worker should be a similar experience than deploying on a zone Worker (modulo Wrangler's config).

• I can imagine using zoneless Workers for expirementing (where you just want a random URL) or a better preview/pre-production stage.

[ashleymichal]

the two biggest, most visible differences here are that

1. the user is not provided with their zone id (it does not show up on their dashboard, as what has been provided is a "liberated" zone.)
2. there are no routes to speak of; one's worker bundle is either live on their zoneless subdomain at <worker-name>.<user-subdomain>.workers.dev

to make things more complicated, a given account can have the zoneless entitlement _in addition to_ their zoned workers entitlement. the rules stack, and the workers belong to an account, so that one worker can be live both on the workers.dev subdomain, and on a zone/route.

the issue of "multi-script for all" also touches this, but only incidentally, so perhaps that should be a separate issue; suffice to say, folks who currently have single script will see their worker script in their bucket, but named (roughly) after their zone.

[exvuma]

My attempt at a solution to the differences Ashley addressed ^

Similar to how we implemented the serverless tool to support both multi-script/single script and make the config look as similar as possible, I think we should support zoneless/zoned. So have configuring routes look similar e.g. for zoned
the usual route:https://*.ex.com and for zoneless must be explicit route: script.myzoneless.worker.dev* The only field that would differ would be the zone_id for non-workers.dev routes.

I don't think the tool should ever cross-zone scripts. i.e. the tool should add a script to _just one_ zone or _just one_ worker.dev subdomain, never both. If the user wants to configure multiple zones to point to the script the UI/API sure, but the tool shouldn't.

I don't think we should worry about single scripts and assume that everyone will be converted by this point.

[rita3ko]

I don't think users should have to do anything explicit for zoneless. They can define whether or not they want the script to be public. The CLI should spit out the zoneless link after you deploy, kind of like in Nick Balestra's tool.

[exvuma]

Will they be able to determine the name of the script? @rita3ko