Closed
Description
- decorator/export ordering update
- No progress per se
- 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
- Next time!