Closed
Description
External Tools Operating Over Multiple Projects
- What should people expect out of tools supporting TypeScript like esbuild?
- esbuild will always look for the closest
tsconfig.json
- Feels like part of it comes down to thinking about projects vs. code-split outputs maybe?
- Maybe tools never look at TypeScript's
target
etc.?- Less easy to say with the JSX factory.
- useDefineForClassFields?
- swc switches it on.
- Maybe esbuild does now too.
- TypeScript's config is often supposed to be a declarative description of the end runtime.
- We need to come back to this after reading it more deeply.
Implicit Returns with Explicit Return Type Annotations
// Was error, now okay. Should it be an error with `noImplicitReturns`?
let q1 = (): undefined {};
// Was error, now okay. Should it be an error with `noImplicitReturns`?
let q2 = (): string | undefined {};
// Differences with contextual typing?
// Still an error, inconsistent with the above.
let q3 = ()
// No contextual type, will continue to error.
let q4 = () => {}; // inferred as () => void;
let q5: () => undefined = q4;
// Was error (with or without noImplicitReturns), now okay.
// Should it still be an error
let q6 = (): unknown => {};
// Was 'Not all code paths return a value' with noImplicitReturns.
// Now it isn't.
let q7 = (b: boolean): unknown => {
if (b) return 42;
}
- Took a PR to say "if the return type includes
undefined
, we allow implicit returns". - Thought these were caught by
noImplicitReturns
- Returning
undefined
implicitly - 3 states
- I can never return
undefined
- actually can. - I always return
undefined
- implict return is probably okay (at least in some mode?) - I sometimes return
undefined
- (
void
?)
- I can never return
- Does
noImplicitReturns
really mean "no implicit returns every unlessany
andvoid
"- Or bare
undefined
?- Fine. Who the heck does that unless they know what they're doing?
- What about
number | undefined
?
- Or bare
any
andunknown
always swallow up other types.- What about
number | void
?- Usually people mean
unknown
? - Maybe
number | undefined
?
- Usually people mean
- What about
- Contextual types?
- Same issues as empty arrays though. Concerns with capture and constraints affecting the inferences.
- Would like to
- Explicit
undefined
?- Treat that like plain
undefined
.
- Treat that like plain
- Empty body special case for
unknown
?- No.
Divergent Getters and Setters
- Today, getters and setters have to be related.
- But the reality of the DOM APIs in JavaScript is that they don't need to be.
- We've said
foo.bar = foo.bar
should always be allowed.- But again,
document.body.style = document.body.style
makes this not true.
- But again,
- Are there assumptions that we make about the getter based on the setter and vice-versa.
- Indexed access types?
T[keyof T]
?- Read types or write types?
- We always pick the read types.
- Probably should have a lint rule to opt back into the old behavior.
- Could say "only in
.d.ts
files?" - Would get funky.
- DOM is one example, but real-world TypeScript code.
- Immer, GraphQL ORMs,
- Could say "only in
- Variance?
- Does a generic only in a
set
parameter make something contravariant? - We never look at the write-type, so the type parameter's variance would be independent.
- Does a generic only in a