Removing Compatibility From Object Types to { [x: number]: any }

#41660

• Kind of strange behavior because numeric index signatures are usually stricter.
• This was never meant to apply to numeric index signatures. We always had string index signatures in mind.
• Would this tightening also apply to symbol, literals, etc.?
  • Currently don't have those index signature types, but we would want the same restrictions.
• Conclusion: seems fine.

const enums and import type

#40344 (comment)

• In the beta period of its release, import type only allowed symbols in type positions.
• Eventually got feedback that the point was all about emit.
• Soon got feedback about const enums in import type because really the emit doesn't rely on it.
  • Seemed reasonable as a suggestion, said "awaiting more feedback", but got internal feedback about this.
• Under isolatedModules, the value no longer inlines.
• Proposal: keep error as-is if isolatedModules is on, but otherwise remove the error for using it in import type.
• People don't always know that they're supposed to use isolatedModules.
  • But that's fundamentally the right thing to do when you use another compiler.
• Narrative feels compelling but...
  • don't feel super strongly about this.
• Feels strange to extend more special-cases for const enums.

Philosophy on ES Modules and the Handbook

• Handbook talks about different module system types.
• Maybe new handbook talks about CommonJS and ES modules.
  • Mention AMD, UMD, System exist, but want to talk about what most people will be doing in their day-to-day.
• All of this is part of an umbrella goal for supporting ES modules in Node in general.
• Strive for at least examples of modules in the browser, in Node.
• Syntax, resolution, output?