Description
paths
without baseUrl
-
One of the things you have to do every single time you set up
paths
is setbaseUrl
. -
baseUrl
makes sense with the browser behavior in mind. -
So why do you need both?
Require.js
legacy reasons.- Unclear, niche scenarios when you use both otherwise?
-
Proposal: whenever there's no
baseUrl
, resolve each path relative to thetsconfig.json
. -
What about non-relative mappings?
{ "compilerOptions": { "paths": { "foo": ["react"], "components": ["./shared/components"], "components/*": ["./shared/components/*"], } } }
-
Also, what about circularities?
{ "compilerOptions": { "paths": { "foo": ["yadda"], "yadda": ["foo"], } } }
-
-
Could always say when there's no
baseUrl
, all paths must be relative. -
Could also use
rootDir
instead oftsconfig.json
location.rootDir
is poorly understood, doesn't do what most people think, don't use it.
-
Conclusion: put put a PR, try it out.
Treat Trailing undefined
/any
/unknown
Parameters as Optional
-
Usually, a promise's resolver callback requires a parameter.
new Promise<number>(resolve => { resolve(); // Error - required 1 parameter of type `number`. });
-
We have some special-cased behavior for
void
- if you havevoid
, then the parameter is considered optional.new Promise<void>(resolve => { resolve(); // Parameter is optional because it's `void`. });
-
Idea: if you have trailing
undefined
orany
orunknown
parameters, then these become optional. -
Problem: this weakens the TypeScript side.
- Considering only doing this for TypeScript.
-
People definitely don't want
strict
. -
Does
--strict
with JavaScript make sense? Is it coherent!- Yes! ish
-
So only outside of
strictNullChecks
?- Sure!
- *tries it out*
- uh oh,
number | undefined
becomesnumber
outside ofstrictNullChecks
😬
-
Conclusion: try without
strictNullChecks
, check with @sandersn.
Update on Recursive Conditional Types
- OOM issues due to the switch to use
isDeeplyNestedType
for recursion tracking. - Pathological examples where we do enormous amounts of work.
- If you're inferring from 2 type references, and you come back to the same type references, you often don't get helpful inferences.
- The reason we do "up to 5 levels of exploration" in inference is that we do get a little further with type references when inferring from
Box2<Box2<string>>
toBox1<Box1<T>>
. - Newest commits just track just 1 level of recursion. As soon as we see 2 types with identical "recursion identities" (new concept that relates potentially-recursive constructs back to their origin location), we stop.
- Have some fix-ups for literal types - object literals aren't recursive.
- Sure they are!
- What about a getter with
this
?- Oh no
- What about a getter with
- Sure they are!