Restricting Mixing module and moduleResolution when one is node*

#54567

• Stuff gets weird when you mix module and moduleResolution.
• The first reason to explore this change was we were writing docs that explain what these do.
  • moduleResolution is somewhat straightforward; not module.
  • Conceptually, moduleResolution is strictly path lookups, module decides emit, and is driven by a local package.json, etc.
    • However we've seen that some of this behavior has leaked.
• So we would like to make the docs clearer, but we need to understand this all better ourselves!
• What happens when you error when they don't match up? Some examples:
  • cheerio
    • dual CJS/ESM build
    • ESM build does --moduleResolution node16 --module esnext
    • CJS does --moduleResolution node16 --module esnext
      • Seems fine, but is a footgun. Assumes everything will be CJS, resolution will go badly.
    • Node 16 users are getting the wrong types from this package.
    • But the use-case of dual emit is valid and the paths forward today are not great.
  • docusaurus
    • actually should be using --moduleResolution bundler
• --module esnext --moduleResolution node16?
  • Forcing a dev to say "no the module has to be node16 as well has no downsides.
• We tried to generalize...but people don't exactly appreciate the degrees of flexibility.
  • Can we deprecate?
• Aside - so many of the base @tsconfig packages use an invalid mix!
  • --module node16 --moduleResolution node!!!!!
• Would be great if package.json supported multiple values for the types field depending on path/directory. - but by the time Node runtimes broadly support this, it will be a bit.
• Feels plausible (desirable) to ban sooner than a long deprecation period.
• Need to update all the @tsconfig

Naming of Diposable

#54505 (comment)

• Disposable vs. DisposableLike.
• It didn't feel ideal to use Iterator for iterator methods, and felt like there was some agreement in committee about placement being off; but ultimately JS can't really support extension methods, and needed an instance and constructor with a prototype so that these Iterator objects can have methods called on them.
• Disposable feels... different? It's a one-and-done concept. There's no chaining.
• There also already is an instance one can use today - DisposableStack.
• So there's less likelihood of it becoming a value global.
• No other language with a disposable concept (destructors, Drop, IDisposable, ...) has more than a single method.
• Conclusion: stop worrying and love the destructor.