Description
decorator/export ordering update
JSIDL
Possible thing for us to parse for dom lib generation
Why not TS?
Why not Flow?
Why not Zoidberg?
Some members are salty about interface keyword being stomped by TS
Dynamic modules has been cut back to the minimum thing needed
Denoting an expression as a literal
e.g. suggestion: explicit "tuple" syntax #16656
Option: Add new syntax
All of it is fairly gross
Option: Push const initializers and parameter values closer to the non-widening area
What about using control flow analysis to allow for initialized discriminated unions to be correctly identified?
The intent of some code is really unclear
What should foo<T>(x: T): T do with e.g. { kind: "bar"} ? Return { kind: "bar" } or { kind: string } ? Arguable both ways
Anders tried inferring a tuple for all arrays of more than 1 element... broke lots of stuff
What about detecting local mutations and choosing a non-widened type when there are none?
Breaks down in some cases (e.g. aliasing, which we're already highly unsound to)
Would be rather wrong in closure situations
konst
:sad shrug:
Infer array rest as tuple if possible #26070 Infer rest as tuple in binding patterns
Certainly fine/correct in zero-order case
👍
Resolve tsconfig.json extends path using node_modules resolution logic #18865 Use node module resolution for tsconfig extends files
👍
Add showconfig too
What about tsconfig.js?
Nooooooooooooooooooooooooooooo
ADTs with inheritance #20144 / Allow any key type as an index signature parameter type #26797 Regex types and index signatures, the peanut butter and chocolate of object types
Reactions are currently unavailable
You can’t perform that action at this time.
interfacekeyword being stomped by TSconstinitializers and parameter values closer to the non-widening areafoo<T>(x: T): Tdo with e.g.{ kind: "bar"}? Return{ kind: "bar" }or{ kind: string }? Arguable both wayskonstextendspath using node_modules resolution logic #18865 Use node module resolution for tsconfig extends files