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, 1/13/2017 #13475

Closed
DanielRosenwasser opened this issue Jan 13, 2017 · 0 comments
Closed

Design Meeting Notes, 1/13/2017 #13475

DanielRosenwasser opened this issue Jan 13, 2017 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Using UMD as a global in a module (#10178)

Bill: How do I reference the globally available value of a library when using a module?

  • Currently, bundlers like Webpack & Rollup have a way to say that "whenever I import a module, it should refer to this global value."
  • But there's no way for TypeScript to just use it as a global.
  • The reason we don't do this is because we're not sure if you're making a mistake.
    • Depending on the UMD pattern that a library uses, they may conditionally define a global variable.
  • Seems strange that you would want to mix and match globals and modules.
    • From a guidance perspective, you may be better off sticking to one style.
  • How many modules conditionally declare a global?
    • We'd have to find out.

Resolution:

  • Put both in scope
  • Have a flag that completely gets rid of the global (both for values and types).

Allowing Dotted Access for Types with String Index Signatures (#12596)

  • Should we allow it or not?
  • Example: trying to work with JSON is a pain; have to use any to access arbitrary properties.
  • There's less safety, but it is a weird inconsistency.
  • Resolution: Allow it.

Allow class to extend from generic type parameter (#4890)

  • Intersection type is not correct to use.
  • We'd really need an extends type operator that keeps the this type and lets the derived class' properties "win out".
    • If we did this, we would not be able to report errors when incorrectly extending in some cases.
      • That's a type hole that we'd have to acknowledge.
      • Though structural checks will often save you anyhow when you have the most derived types.
      • But not necessarily any worse than other type holes we have (e.g. this types in param positions)
    • This also allows you to technically extend things other than classes.
  • We also need to consider how this plays with constructors - we'd like to be able to track the construct signature from the base.
  • Will continue to ponder about the type arithmetic, work with those who're interested (e.g. @wycats).
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 13, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant