Using UMD as a global in a module (#10178)

Bill: How do I reference the globally available value of a library when using a module?

• Currently, bundlers like Webpack & Rollup have a way to say that "whenever I import a module, it should refer to this global value."
• But there's no way for TypeScript to just use it as a global.
• The reason we don't do this is because we're not sure if you're making a mistake.
  • Depending on the UMD pattern that a library uses, they may conditionally define a global variable.
• Seems strange that you would want to mix and match globals and modules.
  • From a guidance perspective, you may be better off sticking to one style.
• How many modules conditionally declare a global?
  • We'd have to find out.

Resolution:

• Put both in scope
• Have a flag that completely gets rid of the global (both for values and types).

Allowing Dotted Access for Types with String Index Signatures (#12596)

• Should we allow it or not?
• Example: trying to work with JSON is a pain; have to use any to access arbitrary properties.
• There's less safety, but it is a weird inconsistency.
• Resolution: Allow it.

Allow class to extend from generic type parameter (#4890)

• Intersection type is not correct to use.
• We'd really need an extends type operator that keeps the this type and lets the derived class' properties "win out".
  • If we did this, we would not be able to report errors when incorrectly extending in some cases.
    • That's a type hole that we'd have to acknowledge.
    • Though structural checks will often save you anyhow when you have the most derived types.
    • But not necessarily any worse than other type holes we have (e.g. this types in param positions)
  • This also allows you to technically extend things other than classes.
• We also need to consider how this plays with constructors - we'd like to be able to track the construct signature from the base.
• Will continue to ponder about the type arithmetic, work with those who're interested (e.g. @wycats).