Closed
Description
Having JSON.stringify(expr)
return string | undefined
- We approved an issue about
JSON.stringify
potentially returningundefined
.JSON.stringify(function() {})
->undefined
JSON.stringify(undefined)
->undefined
JSON.stringify(Symbol())
->undefined
JSON.stringify({ toJSON() {} })
-> 🤷♀️JSON.stringify(?????)
->string
- Thinking
JSON.stringify(object | undefined)
->string | undefined
JSON.stringify(any)
->string
- What are the goals?
- Should've said it was
string | undefined
from the beginning, butstrictNullChecks
came later and we didn't wanna break people. - Fixing this is a fool's errand.
- Won't fix?
- Can't fix, won't fix, don't know how to fix.
- The cure is worse than the disease.
Upper Bounds of Types Resolved to any
- Should we specially interpret function
fn<T extends U>(arg: T)
whenU
is a type that resolves toany
?- Substituting a type with
any
ideally shouldn't break existing code. - But users were using this to say "from the outside, I'm sound, from the inside I'm not".
- Substituting a type with
- Using
any
as a type constraint is a foot-gun.- But
any
itself is a foot-gun.
- But
- What about syntactic
any
being different?- Could give an error on syntactic
any
: "you meanunknown
" - Seems strange.
- Could give an error on syntactic
extends any
might be meaningful, but 50% of the time that meaning might not be obvious to people, causes more bugs.- Conclusion
- Reconsider with more feedback
- No plans for servicing release
Emitting empty export lists, and other fun problems with bundlers
-
Do we need to start emitting
export {}
?- Maybe not for empty modules.
-
We're not emitting
export {}
for value-ful modules though.export type Yadda = any; var a = 10; export { };
- Affects other stuff (e.g. strict mode)
- We also don't emit anything in empty files when
alwaysStrict
is on.- Because we assume that, well, it's a module.
-
Weird because we emit
export {}
for.d.ts
files. -
Conclusion
- Don't restore
export *
behavior - Evaluate where
export {}
may need to be injected.
- Don't restore