dom.iterable and dom.asynciterable in tsconfig.json

• Move Iterable/AsyncIterable into main DOM/WebWorker libs #62111

• Consistent annoyance is that lib: ["dom"] doesn't include "dom.iterable" or "dom.asynciterable".

• 90402e7: If you have DOM and es2015, then we automatically add dom.iterable.

  • Doesn't disrupt file layout, but it is a little hacky.

• Move Iterable/AsyncIterable into main DOM/WebWorker libs #62111: Stick dom.iterable into the dom lib automatically, force dom to include lib: es2015, dom.iterable references dom (maybe doesn't have to, can just be empty).

  • Gotcha: There's also async iterables in the DOM. Those are defined later than ES2015.
  • Shouldn't we include those too?
  • So snap to ES2020 or something?
  • And what about Disposable/AsyncDisposable? Those might go into the DOM too.

• DOM is effectively evergreen - we try to include things only when we have 2 distinct implementers shipping.

  • So maybe this should just pull in esnext?

• On the other hand, you never know when implementers will have disagreements. So could just have explicit references to es2018.asynciterable and es2015.iterable. These additions are pretty rare.

import with { type: "bytes" }

import someBytes from "./someFile" with { type: "bytes" };

• Always creates an immutable default export that's a Uint8Array.

• Think including images, wasm files, etc.

• How do you model this? New syntax for ambient modules?

  declare module "*" with { type: "bytes" } {
    var x: Uint8Array;
    export default x;
  }

  • Problem with this - it masks file lookup failures. You really want to know if the file does/doesn't exist.
    • Do you? Will these files be in the input/source directory? The output?
  • But we're not going to do file inclusion, some other tool is.
    • Right?
  • But we include JSON into the output, so why not these?
    • That might've been a mistake.

• Mixed feelings on this.

• We may not need new syntax, it is fine to just understand that { type: "bytes" } means Uint8Array.