Library Reference Overrides / Overrides for /// <reference lib />

#45518

• Makes it so people don't have to upgrade DOM types until they want to.
• Ideas
  • Pragma inside your code that allows TypeScript files to state overrides.
  • This PR (Adds support for overwriting lib references via the TSConfig  #45518) just does a tsconfig.json override.
    • Without further demand, the PR won't implement the pragma.
• A little hacky right now - have to do some extra JSON stuff in the current implementation.
• This is only because of /// <reference lib /> syntax. There's no way to really get rid of these in the first place.
  • Basically.
  • https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html
• This is a redirect - what about excluding instead?
  • Is this a legitimate concern?
  • Kinda!
  • Want to have a way to ignore library from the build.
  • Or you want to include several files in its place.
  • "ignore-lib": ["dom"]?
  • "lib": ["!dom"]?
• Fine if you're an end-user, but what if you're a library?
  • Our stance is your library code shouldn't be expressing an explicit dependency in this way.
• We can give some good error messages.
• Seems like we can get away with just exclusions/ignores, then you don't need replacements.
• Some of us like the "simplicity" of -dom and !dom.
  • One of the downsides though, is the fact that a user might have forgotten that
  • Also would be able to put it in a /// <reference lib="!dom" />?
    • But we didn't want that.
    • Would want these not to work.
  • Also, people will want this for the types array.
    • We've said "if it's in your compilation, then it's in your compilation 'for a reason'."
• This is a dependency management problem - so leverage package managers?
  • Look in a few default locations (e.g. @typescript/es2019)
  • Need to provide guidance on how to create dependencies.
  • Can npm actually deal with overrides?
    • Hard to.
    • Node.js policies are kind of the direction here.
  • Solved in the hypothetical future, but wouldn't work for now unless we have
• Also want to have better context across package managers including npm.
• Conclusion:
  • Orta Therox (@orta) to iterate on existing PR based on feedback here.
  • Need to sit and think on some of the "resolve from node_modules ideas. Wesley Wigham (@weswigham) will need to give some written details on what this looks like.

Handling Stack Overflows from Instantiations Across Runtimes

#45576

• Issues with inferring from a deeply-recursive type to a deeply-recursive mapped type.
• Now a type in the DOM is deeply-recursive.
• Part of the issue here is that mapped types try to eagerly operate on array types when they run into them.
• We increased our instantiation depth limit from 50 to 500.
  • On some browsers, that's high enough to cause a stack overflow.
• Might have to go back to a depth limit of 100 instead - so how do we keep the same wins from before?
• Rewriting type instantiation logic to trampoline is scary.
  • Quick aside: trampolining in this context is replacing recursion by preserving state across calls, either through continuation passing style and closures or generators and state machines.
• One thing we're experimenting with is tail recursion in recursive conditional types.

  • Have to end in the original type reference.

  • Now you can write string trimming logic that happily chomps away at whitespace and never takes up any stack space.

    type ChompLeft<T> = T extends ` ${infer U}` ? ChompLeft<T> : T;

  • "Fails" if your branch ends in a union instead, but users can encode that with an accumulator.

• Is there a limit to tail-calling?
  • We think we should probably have one.
• Do we need to do anything for TypeScript 4.4?
  • No, didn't increase the limit for 4.4.
  • Could've sworn.
  • No, no, the bug report used a nightly playground.
• So glad we didn't bumpt the limit in 4.4
  • But we still introduced this highly undsirable circularity (which is accurate!) issue.
• Conclusion:
  • Most of the team seems enthusiastic about tail-calling on conditionals.
  • Anders Hejlsberg (@ahejlsberg) to play with that and the recursion depth limit again.