Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 3/3/2021 #43069

Closed
DanielRosenwasser opened this issue Mar 3, 2021 · 0 comments
Closed

Design Meeting Notes, 3/3/2021 #43069

DanielRosenwasser opened this issue Mar 3, 2021 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Mar 3, 2021

Lazily Compute Module Shapes/APIs in --incremental

#42960

  • When we are emitting all files under --watch, we generate a .tsbuildinfo file.
  • Idea is, don't generate the .d.ts emit for a file the first time.
  • Only when a single file changes, that's when we'll compute the change.
  • But when we have composite, we'll still have to do the .d.ts emit.
    • So, unclear if this is what you want for composite.
  • The first change in any file will be unpredictable.
  • Aside: do we need to hash .d.ts emit?
    • We could come up with an alternative - but .d.ts is convenient.
  • So you have to do more work on the subsequent change?
    • Well, you're moving it to later.
    • Kind of amortizing it.
  • So with the composite flag, ideally we'd want to reuse the .d.ts files since you're redoing all the same work.
    • Is that possible?
  • If you're using this for just type-checking with --noEmit, the up-front benefit is great.
  • When do you lose?
    • tsc --watch, read the news, make a change, and a re-check is not that fast.
    • Is that compelling enough for a flag?
    • Seems like no, nobody feels strongly enough.
  • We want the change, need to review it.

assumeChangesAffectShape for --incremental and --watch scenarios

#41219

  • If you don't have .d.ts emit enabled, you have to still pay for the cost of .d.ts emit.
  • Idea: instead of consulting your .d.ts files, every change impacts your dependencies.
  • Can we test with existing teams?
    • They likely already have .d.ts emit, not ideal
  • Let's revisit.

Re-relax Index Signature Requirements

#43065

  • Really, we're expanding the checks to cover 2 new cases.
    • SomeObject -> { [x: string]: any }
    • SomeObject -> { [x: string]: any, [x: number]: any }
  • Doesn't work for intersections of like { [x: string]: any } & { [x: number]: any } - kind of esoteric though.
  • No objections - looking for code review.

Experiments in Narrowing Generics

interface A {
    a: number | null;
}

function get<T, K extends keyof T>(obj: T, key: K) {
    let p = obj[key];
    if (p !== null) {
        let x: number = p; // doesn't narrow!
    }
}
  • Want to be able to say when a type variable has a constraint, you want to lift that constraint up to an intersection of the type variable and its constraint.
    • T extends "a" | "b"
    • -> T & ("a" | "b")
    • -> T & "a" | T & "b".
  • Once you do that, you can narrow those intersections with x === "a" and x === "b" accordingly.
  • Reminds some of us of negated types.
  • With negated types, we had perf problems of generating a ton of types.
    • What about a constraint of IntrinsicElements or something?
    • Is this something where we could have a size limit?
  • Will this introduce a lot of subtype reduction?
    • Think most code will have no effect at all?
  • If we could make this efficient, could we do negated types?
    • That's not why we didn't do negated types.
    • "Yeah, but that's why I stopped bringing them up"
    • 🤨
  • Do we manufacture these unions of intersection lazily?
    • Unclear - sounds like yes?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant