Design Meeting Notes, 6/28/2019

[DanielRosenwasser]

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 @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.

[treybrisbane]

@DanielRosenwasser I've noticed a big drop in the frequency at which these notes are posted. Has there been some internal process change around this? Should we expect to see more or less notes being posted going forward?

The team I work with makes heavy use of TypeScript, and these notes have proven to be a highly valuable insight into the mindset and direction of the TypeScript team. :) It'd be a shame if y'all were unable to continue posting them.

I understand that you're a small team, so no hard feelings if you're unable to continue providing these notes. Just wondering what we should expect going forward! :)

[DanielRosenwasser]

We just haven't had design meetings as frequently, with people often being out since it's summer. Hopefully more coming soon!

[treybrisbane]

Ahhh, no worries then! :)

Cheers for the update!