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, 7/31/2020 #39852

Closed
DanielRosenwasser opened this issue Jul 31, 2020 · 1 comment
Closed

Design Meeting Notes, 7/31/2020 #39852

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

Comments

@DanielRosenwasser
Copy link
Member

Make Direct Assignments to CommonJS Exports Considered Literal Contexts

#39816

  • In JavaScript, module.exports.yadda = ... is considered read-only already.
  • What about module.exports = { yadda: ... }?
  • This PR makes it so we consider that when we decide the types are literals or unique symbols.
  • Technically a breaking change.
    • At earliest, 4.1
  • This would be the only place where we infer an object literal to have readonly properties.
  • Let's see how the user code suite works with this.
  • Because it's only CommonJS, maybe we should just leave it alone.
  • Probably merits no breakage if we see any.
  • Merge otherwise.

Variadic Tuples in Promise.all

#39796

  • With Promise.all, we have like 8 overloads.
  • They don't handle functions with optional members or with rest elements.
    • Means you end up with a weakly typed result from Promise.all.
  • Variadics can handle all these great cases that overloads can't!
  • Technically a breaking change because people could give explicit type arguments.
  • Sounds rare
    • 2 instances in VS Code
  • This also brings up a question about the awaited type.
    • How many levels should the approximated Awaited type in the PR handle?
  • We want T | Promise<T> to ensure that T is not a Promise.
    • But Promise itself can be constructed with an unconstrained type parameter.
  • Will we ever solve this?
  • Would be willing to try in 4.1.

Auto-Imports Slowdown

#38923

  • We should always keep in mind that when these auto-magic features are supposed to make things really good, but then turn everything to crap.
  • We could have a threshold of packages that are not already imported. If you have more than N packages, we don't do the work.
  • We have a flag to turn things off: auto, off, and on.
    • Technically it's off, dependencies, devDependencies.
  • We could do a low threshold - like 10 packages.
  • Can we have editors communicate more than "loading JS/TS language features"?
    • Signaling exactly what we're working on to communicate that something can be turned on.
  • Have to discuss some sort of mitigation plan
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jul 31, 2020
@sheetalkamat
Copy link
Member

sheetalkamat commented Aug 3, 2020

#39816

If we take this PR it also needs to handle json file import? Because we say json import behaves like writing module.exports = json.
Note that with json it is questionable if user intended literal type or not but we have had some issues being reported about it. And for clarity it seems json should behave like js export =.

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

2 participants