Waiting on denoland/typescript-go#31

Wouldn't it have made more sense to reference lib.temporal.d.ts from deno.ns due to it being baked into the runtime?

As a case in point, the current suggestion for type checking in combined browser and Deno environments is to use:

{
  "compilerOptions": {
    "lib": ["dom", "deno.ns"]
  }
}

I think it would be even better to reference it from esnext as that's what TS 6.0 will ultimately end up doing anyways.

Aside, if you'd like to enable the Temporal API separately (in above scenario), then the current config.json schema does not even consider temporal or deno.temporal or esnext.temporal a valid option.

@maikdevries feel free to open a PR to change it

I'd be happy to do so but first need some clarifications:

1. The esnext lib already references esnext.temporal, so how come the Temporal API is not available when using deno.ns (which references esnext)?
2. The definitions in lib.temporal are still marked as experimental, should they be?

1. I'm not really sure
2. No, it should not be marked as experimental

To answer the first: #32656 seems to have introduced esnext.temporal definitions and removed any references to lib.temporal in the process.

So if I understand correctly, there's nothing for me to do other than wait for the next release and it will sort itself out automatically (both deno.ns enabling Temporal API and the schema for deno.json no longer needing deno.temporal). This still leaves the unused lib.temporal definition file dangling in the repository though.

Good catch - you can try this already with deno canary. But yeah lib.temporal should be removed.