Project References: Using .ts/.tsx when .d.ts Files Aren't Available

#32028

• Basically you can run into situations where if project A depends on project B, and project B isn't built, you try to resolve to the .ts files and potentially dynamically generate .d.ts files on the fly.
• Works pretty well...but what do you do when compiler options differ between the two projects?
  • We thought "maybe we can just create a different program instance" but then you have to decide whether you show errors?
  • Feels like skipping errors is the "right" thing to do
    • How do we handle compile-on-save then? Emit could be wrong if the upstream source is broken.
  • Is skipping errors the right thing to do? People hate when we don't report errors.
    • Well, VS Code wouldn't ask anyway.
    • VS would
• What about compiler flags on a per-file basis?
  • Could imagine you have consistent behavior at production-site, special-case in consumption-sites.
  • noImplicitAny and noImplicitThis make sense. strictNullChecks might not?
    • Have to walk up the spine to figure out what the types are when you resolve types.
• What are some scenarios you'd want to change between projects?
  • Strictness makes sense for migrations.
  • We already handle module resolution(!?)
  • lib, target, module.
• The options are (revisit this Sheetal Nandi (@sheetalkamat))
  • either to assume those files are part of your project
  • or try to lazily pull on
  • or to generate .d.ts files
  • or to pull on types when they're annotated and not infer from the body.
• Maybe we should try to publish some solution to typescript@experimental and see how it works.
• What about compile on save?
  • Either implicitly do it for everyone or force every project to opt in
  • Probably best to error if some projects and some use it
  • There's a compilerOnSave in showConfig.
• Action items: Ensure that you can at least inherit compileOnSave and give errors if not all projects use it; then in the PR disable errors on external source files, disable emit,

Array.isArray, unknown, and ReadonlyArray

#28916

• Array.isArray narrows down number | ReadonlyArray<number> to any[]!
• [[Pair program section across almost the entire team.]]
  • Looks like we can do this with a conditional type
  • Signature looks terrible.

Control Flow Analysis on Element Access Expressions

#31478

• For using literals in element accesses, this is fairly cheap overall.
• As soon as you do this for arbitrary identifiers, then you start seeing some explosions in the control flow graph.
  • Follow-up: What if instead of string literals you used identifiers with types of string literals?
    • Probably the same behavior.