Closed
Description
-
Should we put
Omit
in lib.d.ts? AddOmit
as a known interface #30455- In principle, no objections
- What are the breakages?
- 1 package on DT was impacted
- BigTsQuery found 3 programs
- The fix is trivial
- Should we constrain
K
in the official definition?- Nah
Extract
is not constrained either- The type can resolve either way
- 👍
-
Changing the default type constraint from
{}
tounknown
Change the default type parameter constraints and defaults to unknown from {} #30637- Zero breaks on DT because Wesley fixed them
- Breaks in RWC were in places where things actually could be null/undefined
- 2-3 files where this happened
- Typically e.g.
foo<T>(x: T) { x.hasOwnProperty(...)}
- Should we issue custom error messages?
- Nah
- 👍
-
JSDoc feature parity [Design Policy] Consider JSDoc feature parity with Typescript #30624
object
: Fine to treat this asobject
in input positions, but in output positions this is fatal because JS is often under-specifiedString
/string
has a similar probleminterface
- can'textend
something- Key question: Should everything you can write in TS have a JSDoc equivalent?
- You want something like "Let me write TS in this JSDoc comment"
- We don't want to be inventing JSDoc syntax for all of our stuff
- "Inline declaration file"
- Why not make a .d.ts file?
- Scoping alignment
- Comparison with flow's
::
syntax- Is
/* ::
widely-used amongst flow programmers?
- Is
/** @ts ...
- What is the lexical scoping of this?
- What are the legal positions of this sort of comment?
- Legal at positions where a declaration would have been permitted
- Type arguments (?)
- Is this for annotation of functions, or for top-level declarations?
- Both
- How do you write module-scoped types?
- Merge module scopes .js and .d.ts files of the same name?
- What about the straightforward parser limitations?
- What are the use cases?
- "We exist on a line, not a square"
- But this complicates the transitional story
- It's important that we not add "false paths" of syntax that can't be transitioned
- We started out to understand JS Doc, not invent new syntax
- We're not going to support everything
- Need to stop adding new JSDoc-specific behavior
- Stake in the ground: Full feature parity is not a goal
- We should be supporting extant JSDoc
- Why not make a .d.ts file?
as const
should work in JSDoc cast syntax (bug)