Provide an easier way to configure type checking for other runtimes

[kt3k]

Currently it's difficult to configure Deno type checking to make it work with browsers.

If you like to write code which works with browsers instead of Deno, you need to configure deno.json into something like the below:

{
  "compilerOptions": {
    "lib": ["esnext", "dom", "dom.iterable"]
  }
}

This requires a lot of knowledge about tsconfig.json, and this situation seems against our zero-config/easier TypeScript principle.

I'd suggest we should have runtime field in deno.json, which accepts a list of "deno" | "browser" (for now), and that fields configures the type checking automatically for each given runtime.

{ "runtime": ["browser"] } //=> `compilerOptions.lib` becomes `["esnext", "dom", "dom.iterable"]`

For SSR situation:

{ "runtime": ["deno", "browser"] } //=> `compilerOptions.lib` becomes `["deno.ns", "esnext", "dom", "dom.iterable"]`

[raashidanwar]

I think I can pick this up. I guess this would require to make changes in deno_json as well.

[raashidanwar]

@bartlomieju created a pull request https://github.com/denoland/deno_config/pull/130.

[BlackAsLight]

What happens in the event that both runtime and lib properties are provided?

[bartlomieju]

What happens in the event that both runtime and lib properties are provided?

Most likely a warning or an error.

[kt3k]

Warning makes sense when lib and runtime options conflict. But how about merging them when the both configurations have no overlaps? I guess some users might want to use their own type definition in addition to the runtime presets

[raashidanwar]

pe definition in ad

I think merging with unique values would do the work, why do we even care about conflict?

[bartlomieju]

Discussed with the team, if both options provided it should be a hard error.

[JOTSR]

I have some questions about this issue that I hope are not too out of scope:

1. This feature seems to be like the way we define runtime support on jsr, does it will be also used as standard jsr package entry ?
2. If (1) and for forward compatibility does the runtime entries have to be semver tagged to ensure API support between the runtime and the package (like package.json engines key) in a simpler shape { "runtime": ["deno@2", "[email protected]"] } or in full (see). It will so raise an meaning full error message during package installation or resolution instead of during runtime.
3. Supposing (1) and (2) how to semver tag browser. It seems to be many way to do it but using a per browser key (["chrome@102", "safari@^13.3"]) is fastidious and not future proof. I think there are at least 3 interesting solutions:
   • Using the web platform baseline (["browser:baseline@2023"]) or (["browser@b2023"]) or any similar syntax, note that we refers to "baseline" in the tag to be future proof if the baseline initiative ends or change.
   • Using the tc39 version freeze (["browser:es@2021"]) or new key (["es2022"]) like in tsconfig.target.
   • Using both.

[kt3k]

@JOTSR

This feature seems to be like the way we define runtime support on jsr, does it will be also used as standard jsr package entry ?

Currently there's no plan to use this for defining package compatiblity in JSR. I think that idea would be better discussed in JSR repository https://github.com/jsr-io/jsr/issues