Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 5/15/2020 #38694

Closed
DanielRosenwasser opened this issue May 20, 2020 · 1 comment
Closed

Design Meeting Notes, 5/15/2020 #38694

DanielRosenwasser opened this issue May 20, 2020 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Having JSON.stringify(expr) return string | undefined

#38574

  • We approved an issue about JSON.stringify potentially returning undefined.
    • 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, but strictNullChecks 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

#38555
#29571

  • Should we specially interpret function fn<T extends U>(arg: T) when U is a type that resolves to any?
    • 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".
  • Using any as a type constraint is a foot-gun.
    • But any itself is a foot-gun.
  • What about syntactic any being different?
    • Could give an error on syntactic any: "you mean unknown"
    • Seems strange.
  • 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

webpack/webpack#10889

  • 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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 20, 2020
@DanielRosenwasser DanielRosenwasser changed the title Design Meeting Notes, 5/20/2020 Design Meeting Notes, 5/15/2020 May 20, 2020
@reverofevil
Copy link

reverofevil commented Mar 7, 2021

don't know how to fix

Nice.

we didn't wanna break people.

Right now it crashes productions all over the world. As much as backcompat is an issue, this change could be pushed in a major version of TS (oh, it could have been TS 4, if anyone cared).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

3 participants