Suggestion(Deno.emit): Add option for enabling unstable APIs in EmitOptions

[kt3k]

When you transpile the code which include Deno's unstable APIs, you need to specify "deno.unstable" lib in compilerOptions.

await Deno.emit("https://deno.land/posts/v1.7/dig.ts", {
  compilerOptions: {
    lib: ["deno.unstable", "deno.window"],
  }
});

This could be hard for the users to figure out. So I suggest we should have the option for it.

await Deno.emit("https://deno.land/posts/v1.7/dig.ts", {
  unstable: true // => enables unstable APIs of Deno
});

ref #8800

[caspervonb]

Hmm, couldn't we just solve this with a doc example instead?

[kt3k]

@caspervonb I agree that could be another solution.

@kitsonk What do you think?

[nayeemrmn]

I agree, I think unstable should be where e.g. check is, but unfortunately it belongs where it is currently is as well. This is another reason we should remove tsconfigs (#7732). One they're gone from the CLI, I think it'll be more clear that the runtime compiler also doesn't need them.

[kitsonk]

@nayeemrmn removing it for code the Deno runs is one thing... Removing it for Deno.emit() would severely limit the ability to use Deno.emit() as a multi-purpose compiler/transpiler/typechecker. I would be strongly opposed to removing it from Deno.emit().

I feel the options should reflect the command line. While check is inverted, it is still follows the command line. I believe unstable should be added, which is why I asked @kt3k who brought it up to raise an issue, as to get it to work is arbitrarily complex for users, and something we could easily support in options. I also realise, we should support a type option as well, which defaults to "window" but accepts either "window" | "worker".

[nayeemrmn]

Removing it for Deno.emit() would severely limit the ability to use Deno.emit() as a multi-purpose compiler/transpiler/typechecker.

I'm not saying we should remove configuration, but we shouldn't blindly grab tsc's design and everything that comes with it. There are compiler options that are expressly not endorsed by Deno's TS in CLI like less strict modes, and "Deno's TS" remains a simple concept as a result as long as the runtime compiler also excludes them. There are some options there that are outright bad, like linting rules. We even included things that the TS team regret. I don't think "multi-purpose" should include anything outside of Deno and browsers. Global libs can be configurable, but for example the inclusion of JS built-ins shouldn't be to that level.

[kitsonk]

I'm not saying we should remove configuration, but we shouldn't blindly grab tsc's design and everything that comes with it. There are compiler options that are expressly not endorsed by Deno's TS in CLI like less strict modes, and "Deno's TS" remains a simple concept as a result as long as the runtime compiler also excludes them. There are some options there that are outright bad, like linting rules. We even included things that the TS team regret. I don't think "multi-purpose" should include anything outside of Deno and browsers. Global libs can be configurable, but for example the inclusion of JS built-ins shouldn't be to that level.

There are quite a few options we ignore/don't process for Deno.emit(). Not as many as --config. The ones that are supported are in the types. Further refinement of those that are things the "TS team regret" can be suggested to be removed/ignored, but that all seems out of the scope of this issue.