Typescript: Suggestion Backlog Slog, 4/1/2019

[RyanCavanaugh]

• #30000 Allow use of always-initialized (according to types) variables
• #22991 Support max-line-length in Organize Imports refactor
• #13195 Distinguish missing and undefined
• #29732 Overloads and mapped types, what's going on
• #30017 Contextual typing of singly-used functions?
• #12607 Allow augmentation of re-exported modules
• #27379 Allow providing additional files with tsconfig.json
• #28339 Mapped types should distribute over unions
• #29651 Transpile-only builds
• #29786 Use generic defaults in Map/Set ctors (observed contextual type)
• #29293 Show unused public properties and methods
• #30690 as const on enum values
• #30511 skipLibCheck for skipping only "external" files
• #27089 Object.keys ES5 input type

[RyanCavanaugh]

• #30000 Allow use of always-initialized (according to types) variables
  
  
  
  • Ideally not an error, of course
  
  
  • How is uninitialization detected?
  
  
  • Currently switch exhaustiveness is only for return statements themselves
  
  
  • CFA does not have the type information to know that the no-op switch path is "unreachable"
  
  
  • Requires multi-pass CFA / typechecking
  
  
  • DL
  
  
  • let a!: number; and Daniel will log bug on bad error message there
  
  
• #22991 Support max-line-length in Organize Imports refactor
  
  
  
  • Rabbit hole complaining about sort order disagreements
  
  
  • Is this difficult?
    
    
    
    
    
    • ??
    
    
    
  
  
  • Fine
  
  
• #13195 Distinguish missing and undefined
  
  
  
  • Fairly large breaking change; would need to be its own flag
  
  
  • JS lacks a good way to elide a property in an object literal
  
  
  • The in operator doesn't care about observing an undefined
  
  
  • An experiment would be interesting
  
  
• #29732 Overloads and mapped types, what's going on
  
  
  
  • We "need" to do overload resolution during instantiation
  
  
  • We always resolve based on the last signature (pure heuristic)
  
  
  • Is there a unification step we could take?
    
    
    
    
    
    • Hard to say & would definitely lose return type information
    
    
    
  
  
  • As long as there are no generics, and the return types are the same (?), we could try flattening to the tuple form
  
  
  • Anders to ponder
  
  
• #30017 Contextual typing of singly-used functions?
  
  
  
  • This feature looks like a bug in practice
  
  
  • The compelling aspect of this request is the difficulty of writing the type annotation you want here
  
  
  • Some way to resolve a discriminated union in a type position would be nice
  
  
  • Select<T, K, V> is easy to write! (let's see if that's true...)
  
  

// One-time helper, curryable
type Select<T, K extends keyof T, V> = T extends Record<K, V> ? T : never;

// Type annotation
const fooLogic = (foo: Select<Action, "type", "FOO">["foo"]) => { // 👍
    return {/* ... */}
}

• #12607 Allow augmentation of re-exported modules
  
  
  
  • What is actually being described here?
    
    
    
    
    
    • Adding extra stuff to AClass ?
    
    
    
    • Something else?
    
    
    
  
  
  • NMI on what's being asked here
  
  
  • If the request here is to augment AClass through either name, then this is just a bug report of us following import aliases more aggressively
  
  
• #27379 Allow providing additional files with tsconfig.json
  
  
  
  • Sidebar: can we warn when a local tsconfig is being ignored?
    
    
    
    
    
    • Why do we do this?
    
    
    
    • All bad decisions are due to back compat
    
    
    
    • How did we come up with these rules?
    
    
    
    • Worried about breakages in msbuild scenarios
    
    
    
    • Can we print a warning?
    
    
    
    • "Warnings are never a break, right?"
    
    
    
  
  
  • This issue
    
    
    
    
    
    • Does it augment or replace the include list? Or the files list?
    
    
    
    • How does this interact with exclude?
    
    
    
  
  
  • Someone go figure something out
  
  
• #28339 Mapped types should distribute over unions
  
  
  
  • Can't change the behavior here
  
  
  • "Fix" is to use Pick2: type Pick2<T> = T extends T ? Pick<T> : never
  
  
• #29651 Transpile-only builds
  
  
  
  • Comes with same caveats as using noEmit + babel (turn on isolatedModules)
  
  
  • Scenario is using TypeScript as Babel and something else as TypeScript
    
    
    
    
    
    • It's a dessert topping and a floor wax
    
    
    
  
  
  • We're curious how things are for this user under incremental
  
  
  • Effectively noResolve is on?
    
    
    
    
    
    • Yes?
    
    
    
    • No?
    
    
    
  
  
  • It's "easy" to write a tool that does this for you
  
  
  • AMF and more info
  
  
• #30690 as const on enum values
  
  
  
  • :+1:
  
  
  • Allowed only in the case E.P where E is a literal enum
  
  
  • Include negative tests for other stuff
  
  
• #27089 Object.keys ES5 input type
  
  
  
  • Is this a desirable call?
    
    
    
    
    
    • ??
    
    
    
    • Doesn't seem like it
    
    
    
  
  
  • AMF / log an issue
  
  

[zpdDG4gta8XKpMCd]

i am sorry for being a pain in one place, but how come ~these~ first 3 of these and some more features/problems are even considered? it's like the team is out of ideas what to do next

there are 👍 of 250+ problems waiting from the dawn of time, and being ignored for years:
https://github.com/Microsoft/TypeScript/issues?q=sort%3Areactions-%2B1-desc

[RyanCavanaugh]

@aleksey-bykov Probably some context-setting is in order. This meeting is primarily devoted to getting yes-or-no decisions made on suggestions which have fairly clear outcomes. In other words, it's effectively a "shortest job first" throughput-maximizing endeavor where we try to pay down some of the massive triage debt we have while also getting as many suggestions accepted or declined in a short turnaround time. If a dozen people express an identifiable need for a commandline flag to print the errors in reverse order, we should be able to make that yes-or-no decision so they can either send a PR or make other arrangements.

By its nature, this means we're looking at simple commandline flags, tweaks to definitions, highly-scoped behavioral changes, or "Is this actually a bug?" type issues.

For larger high-impact features (HKTs, variadics, nominal types, negated types, etc) we are generally choosing these based on ecosystem need and concerns about implementation complexity. I can't take Associated Types to a room with three people, getting a consensus "yes", and be shipping it later that week - all of these larger things start with a clearly identifiable gap in the language, get discussed at a high level for weeks if not months, and eventually land as a keystone feature in a release.

I have over a thousand pending suggestions to sort out here. In a particularly good week when all the key people are present, we can get through 20-30. Any sort order is necessarily going to give some suggestions the short end of the stick, which sucks, but this meeting literally was created to just get the freakin' number down and its agenda reflects that. Hopefully that clarifies why you see small-ball level suggestions in these notes - it's not because we're eschewing popular stuff, it's that we're trying to get through a bunch of easy decisions all at once.

[zpdDG4gta8XKpMCd]

so you are saying it's not a planning meeting and yet, some requests get approved for implementation, i am questioning the rationale of the original selection, some requests are created a day ago, do not have any comments let along any thumbs up, and yet they are brought for discussion with a chance of being approved, i just dont get this part

[RyanCavanaugh]

It is a planning meeting. It is simply not the planning meeting where All Decisions Get Made, and not the planning meeting where any of the issues you linked to could be meaningfully addressed.

I'm facing the task here of picking 15-30 items from a list of 1,500. My algorithm here is intentionally varied; some weeks I sort by oldest, some weeks most upvotes, some weeks newest, some weeks we work off a backlog of recently-curated things. If you're trying to make an agenda where everyone stays engaged and is making good decisions, it's necessary to keep a mix of things in there.

Sometimes a suggestion comes in and I say, "This would be easy to make a quick decision on", and it goes in the queue. #30690, for example, the first thing we said in the meeting was "This seems like an oversight that it wasn't allowed in the first place".

Getting flak for how we choose to handle this enormous backlog of suggestions is draining and I'm trying to figure out what you want to get out of this conversation. If you want to pitch a list of 15-30 "In Discussion"-tagged items that you think we can make yes-or-no decisions on in five minutes or less each, I will no joke use that as the agenda for the next meeting. Offer is open to anyone; if you want to give us theme weeks or something (Only Commandline Flags! Only C# Keywords!) that'd be fun.

[zpdDG4gta8XKpMCd]

ok, i guess you know what you are doing, thank you for write up

[svieira]

Thank you so much for taking the time to set the context @RyanCavanaugh - the work that you have been doing to make the development process transparent is greatly appreciated (and one of the reasons we're using TypeScript over Flow)