Design Meeting Notes, 3/24/2017

[DanielRosenwasser]

Dynamic Import

• Likely to be in ES2018
• Sometimes you want to have conditional, or lazily loaded, imports.
• Returns a Promise of a module's namespace record.

TypeScript-specific stuff

• When given an explicit string, we can figure things out - otherwise, we need to be explicitly told the type somehow.

• This means that when we run the pre-bind step, it needs to walk the full tree.

  • That has a ~140ms addition - "that's not nothing".
  • Could just track whether it's ever used in the tree, then do a full-walk if so.
  • We need to find a fast way to accomplish this.
  • Salsa already does this - but that's best-effort, and we want to keep the general TypeScript scenario as great as we can.

• When people import "broken up" strings (i.e. import(`hello/${thingHere}/index.js`) can we provide a decent experience?

  • Maybe, down the line.

Proposals to allow people to type untyped imports

1. Use a namespace import where imports get elided.
   • import * as foo from "foo" gets erased if foo is never used as a value.
   • This is too subtle.
2. A new moduleof keyword that takes a string literal.
   • Problem is that you need to cast - not typically
   • Need to bikeshed on the syntax.
     • declare var m: import("./module")
     • declare var m: typeof import("./module")
     • declare var m: moduleof "./module";
     • declare var m: importof "./module";
     • declare var m: typeof "./module";
     • declare var m: module "./module";

Question: do these syntaxes allow qualified names?
* declare var m: (module "./foo").namespace.Interface

We could adopt the import type * as ns from "./a.js".
* This would bring in the namespace import.

Conclusion: let's do the dynamic import, bikeshed offline.

Spread & rest type operators

• spread(T, U) and rest(T, 'a' | 'b' | 'c')

• Concern: what about infinitely expansion & recursion problems.

Spread object literal freshness

var c = { d: 0 };
var o: { a: number, b: string } = {
    a: 0,
    b: "",
    ...c,
    d: 100
};

When you spread in c, you don't know what properties it really has.
So TypeScript doesn't really know if you have excess properties in some cases.

However, d very explicitly appears to be an excess property.
It is statically known to be there - we can always tell.
There is agreement that we should catch that.

What about

var c = {
    a: 0,
    d: 0
}
var o: { a: number } = { a: 0, ...c}

Seems arguable about whether there should be an error.

Conclusion: track freshness on properties, not spreads.

[zpdDG4gta8XKpMCd]

most importantly, speaking of promise like loading, the modules are more than objects, because the modules can contain types (unlike objects) while the promises are for objects only: #8358

[DanielRosenwasser]

@Aleksey-Bykov That's actually what was meant by "This would bring in the namespace import." Namespaces are containers of types and other namespaces.

[DanielRosenwasser]

We actually bikeshedded for a while about whether one of the type import syntaxes should also be usable in a namespace position (e.g. a dotted name).

[RyanCavanaugh]

@DanielRosenwasser need issue numbers here

[aaronbeall]

Thank-you TS team for revisiting the "Spread object literal freshness" issue, this has really made my day and it's super great to see such a responsive team. :) Cheers.