You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
given a type reference, i.e. in tsconfig.json "types" : ["jquery"], or /// <reference types="jquery" />, here are the lookup locations to resolve"jquery"` reference:
location specified by --typesRoot if defined
node_modules
node_module@types
automatic type definition inclusion in compilations, include all "types" packages automatically
value of --typesRoot if specified
the first node_modules\@types walking the spine of the project
The idea here is to simplify type acquisition; all what a user needs to do is
This also works for equality and in switch statements
why only string literals?
yes, string literals are closed. we know the value and the type is the same. we can not make the same assumption about object types.
e.g.
typeMessage={kind: X;a: number}|{kind: Y;b: number};constx: X;if(m.kind===x){// what about if x is also a Y}
down-level generators support
basic level of support, basically for async``await.
extensive level of support for the rest of generators
yelid * support
for..of support for generarots
spread support for generarots
conclusion start with the basic support first, to get async/await support in do the full support later
runtime library (tslib)
__generator is big enough, we do not want to add it in every file.
we need a new library/module for these helpers
__generator will be generated in each file that uses it as we do today. but we will have an option to write it to a different location
The new helper library should include all our helpers
__extends helper
__assign helper
__decorate helper
__param helper
__metadata helper
__awaiter helper
in addition to the generator ones:
__generator helper
Used by the down-level generator transforms to execute a state machine representation of a generator function.
Supports “yield”.
Supports “yield*”.
Supports “iterator.next(v)”.
Supports “iterator.throw(e)”.
Supports “iterator.return(v)”.
Uses magic “iterator” method as an approximation for “Symbol.iterator” in ES5.
Uses “Symbol.iterator” if available.
__keys helper
Creates an Iterator over the keys of an object.
Used to support “yield” inside of a “for..in” loop.
__values helper
If “Symbol.iterator” is available and the argument has a “Symbol.iterator” method, invokes it and returns the result.
If the argument has a magic iterator method, invokes it and returns the result.
If the argument is an array-like, creates an Iterator over the elements of the array.
Used to support “yield” inside of a “for..in” loop.
Used to support “yield” inside of a “for..of” loop.
Used to support “yield*”.
Used to support “for..of” for down-level generators.
Used to support spread for down-level generators.
__takeOne helper
Takes the next value from an iterator.
Used to support array destructuring of down-level generators.
__takeAll helper
Creates an array from the remaining values of an iterator.
Used to support array destructuring of down-level generators.
Used to support spread for down-level generators.
__spread helper
Spreads arguments using __values.
Used to support spread for down-level generators.
The goal for this run time library is to make it available in the following ways:
Published on npm.
Published to one or more CDNs.
Distributed with the compiler?
Using the library with your compilation will be supported with the following compiler options:
Moodes
Inline – Inline helpers (the current default behavior).
None – No helpers (--noEmitHelpers).
Import – (--importHelpers)Import the helpers runtime from a named module in every external module file. Uses helpers from a global namespace for scripts.
--helpersImport – Use the provided module/package name to import helpers (default “tslib”).
The text was updated successfully, but these errors were encountered:
I stopped by to ask a question about --noEmitHelpers and programmatic access to the helper functions' in build scripts, but you guys already have plans, I'm excited to see the runtime library (tslib) notes and #9097 in a future release! 👍
I hope, based on the last few lines on Moodes - None, that --noEmitHelpers will continue to work the way it currently does (TS 1.8), emitting __extends(A, _super) with no __extends implementation?
Automatic type acquisition -- concerns
Some background:
given a type reference, i.e. in tsconfig.json
"types" : ["jquery"]
, or/// <reference types="jquery" />, here are the lookup locations to resolve
"jquery"` reference:--typesRoot
if definedautomatic type definition inclusion in compilations, include all "types" packages automatically
--typesRoot
if specifiednode_modules\@types
walking the spine of the projectThe idea here is to simplify type acquisition; all what a user needs to do is
The problem here is we include files that may not be intended to be part of the compilation
what does
typesRoot
mean:Changes:
typesRoot
an ordered list of strings./node_modules/@types
typeRoots
typeRoots
become the location to automatically include definition filestypeRoots
, or--typeRoots /dev/null
types
in tsconfig.json will disable auto-inclusion as wellADT -- updated
a new kind of type guard is allowed, discriminant gard,
some conditions:
x.prop === expression
x
has to be of union typeprop
has to be of a literal type, string literal type now, but can be extended to numeric literals in the futureexpression
has to be of string type (or numeric when numeric literal types is defined)the type of
x
is narrowed to be the ones that haveprop
with type matching that ofexpression
example:
This also works for equality and in switch statements
why only string literals?
yes, string literals are closed. we know the value and the type is the same. we can not make the same assumption about object types.
e.g.
down-level generators support
async``await
.yelid *
supportfor..of
support for generarotsconclusion start with the basic support first, to get async/await support in do the full support later
runtime library (tslib)
__generator
is big enough, we do not want to add it in every file.we need a new library/module for these helpers
__generator
will be generated in each file that uses it as we do today. but we will have an option to write it to a different locationThe new helper library should include all our helpers
__extends
helper__assign
helper__decorate
helper__param
helper__metadata
helper__awaiter
helperin addition to the generator ones:
__generator
helper__keys
helper__values
helper__takeOne
helper__takeAll
helper__spread
helper__values
.The goal for this run time library is to make it available in the following ways:
Using the library with your compilation will be supported with the following compiler options:
--noEmitHelpers
).--importHelpers
)Import the helpers runtime from a named module in every external module file. Uses helpers from a global namespace for scripts.--helpersImport
– Use the provided module/package name to import helpers (default “tslib”).The text was updated successfully, but these errors were encountered: