Make Service environments the default

[Electroid]

Previously, wrangler had implemented environments using the following algorithm:

function getUrl(name, environment) {
  return environment
    ? `/workers/scripts/${name}-${environment}`
    : `/workers/scripts/${name}`
}

Now, with the introduction of Services, we should change our implementation to be:

function getUrl(name, environment) {
  return `/workers/services/${name}/environments/${environment ?? "production"}`
}

There's also an additional question as to how to handle configurations that migrate from the "legacy" environments to the new Service environments. When a new script/environment is created, the API should return a 201 status code. When wrangler detects this, it should make an additional request to see if there is a "legacy" script. Here's an example:

// > PUT /workers/services/hello/environments/staging -> 200
// Since environment already exists, we're done.

// > PUT /workers/services/world/environments/dev -> 201
// Since environment is new, it's possible we could be replacing a "legacy" script. So check.

// > GET /workers/scripts/world-dev -> 404
// Since no "legacy" script exists, we're done.

// > PUT /workers/services/world/environments/dev -> 201
// Since environment is new, it's possible we could be replacing a "legacy" script. So check.

// > GET /workers/scripts/world-dev -> 200
// A "legacy" script exists, prompt the user about what's changed between wrangler 1 and 2.
// They can either: continue with the new environments, or use the "--legacy-env" flag.

Acceptance criteria:

• All commands use Service environments.
• If --legacy-env is passed, the "legacy" environment algorithm should be used.
• Notifies users if it detects that it's replaced a "legacy" environment.

[threepointone]

Things to verify work well across legacy/service environments -

• migrations
• dev
• secrets
• sites
• tail
• kv
• r2
• publish
• route ...args

Some open questions -

• Apparently we consider the default environment to be 'production'. What happens if someone makes an environment called "production"? This seems like the worst problem.
• What do we do with all the previous projects where we published wrangler environments, but we've now marked all as "production"? Leads to situations like this -
  
• When we run publish --env <name>, should env.<name> exist in wrangler.toml? Otherwise we could potentially publish scripts missing bindings/vars

[threepointone]

First PR - #510 - --legacy-env / config.legacy_env

[threepointone]

Fix routes - #517

[threepointone]

secrets - #523

[threepointone]

tail - #525

[threepointone]

dev #532

[threepointone]

Unassigning this from myself while I work on a couple of other things for a while. The last major thing here is migrations with service envs. After this we need to make a call on the api side, and there may be breaking changes there.

[threepointone]

durable objects #868

[alvgaona]

Any ETA on when this PR is getting merged?

[jspspike]

The adoption of the current implementation of service/environments is on hold for now. There is a new implementation of environments that is being developed this year.

[huv1k]

@jspspike Can we follow somewhere progress? I am really waiting for better information about this one, but can't find anything. Is there anything where I can subscribe to regarding updates? 🤔

[jspspike]

@huv1k Unfortunately the new implementation of environments is currently being postponed for other features. I might have jumped the gun saying that it would be developed this year. I think information about this feature would be released once development has started through issues and PRs on this repository.
That being said the current implementation of service/environments is deprecated and will not be officially supported

[huv1k]

That is sad to hear, hopefully, we will get some solution soon. I don't particularly appreciate that we need to have multiple same workers with different names 🙈

[jspspike]

@huv1k Yes that isn't ideal, if you aren't already using environments in wrangler I would recommend it. You still need to have workers with different names but it helps organize these separate workers