Today we’re happy to announce the availability of our release candidate (RC) of TypeScript 3.4. Our hope is to collect feedback and early issues to ensure our final release is simple to pick up and use right away.<\/p>\n
To get started using the RC, you can get it through NuGet<\/a>, or use npm with the following command:<\/p>\n You can also get editor support by<\/p>\n Let’s explore what’s new in 3.4!<\/p>\n Because TypeScript files are compiled, it introduces an intermediate step between writing and running your code. One of our goals is to minimize built time given any change to your program. One way to do that is by running TypeScript in But it’s unrealistic to expect all<\/em> users to keep a TypeScript 3.4 introduces a new flag called By default with these settings, when we run These As long as nobody else tries writing to the same cache file, we should be able to enjoy faster incremental cold builds.<\/p>\n Part of the intent with composite projects ( When While the file generated by TypeScript 3.4 makes it a little bit easier to use read-only array-like types.<\/p>\n The While it’s often good practice to use TypeScript 3.4 introduces a new syntax for TypeScript 3.4 also introduces new support for The same way that ordinary tuples are types that extend from In earlier versions of TypeScript, we generalized mapped types to operate differently on array-like types. This meant that a mapped type like npm install -g typescript@rc<\/pre>\n<\/div>\n
\n
<\/h2>\n
Faster subsequent builds with the
--incremental<\/code> flag<\/h2>\n--watch<\/code> mode. When a file changes under --watch<\/code> mode, TypeScript is able to use your project’s previously-constructed dependency graph to determine which files could potentially have been affected and need to be re-checked and potentially re-emitted. This can avoid a full type-check and re-emit which can be costly.<\/p>\ntsc --watch<\/code> process running overnight just to have faster builds tomorrow morning. What about cold builds? Over the past few months, we’ve been working to see if there’s a way to save the appropriate information from --watch<\/code> mode to a file and use it from build to build.<\/p>\n--incremental<\/code> which tells TypeScript to save information about the project graph from the last compilation. The next time TypeScript is invoked with --incremental<\/code>, it will use that information to detect the least costly way to type-check and emit changes to your project.<\/p>\n\/\/ tsconfig.json<\/span>\r\n{\r\n \"<\/span>compilerOptions\"<\/span><\/span>:<\/span> {\r\n \"<\/span>incremental\"<\/span><\/span>:<\/span> true<\/span>,\r\n \"<\/span>outDir\"<\/span><\/span>:<\/span> \"<\/span>.\/lib\"<\/span><\/span>\r\n },\r\n \"<\/span>include\"<\/span><\/span>:<\/span> [\"<\/span>.\/src\"<\/span><\/span>]\r\n}<\/pre>\n<\/div>\ntsc<\/code>, TypeScript will look for a file called .tsbuildinfo<\/code> in our output directory (.\/lib<\/code>). If .\/lib\/.tsbuildinfo<\/code> doesn’t exist, it’ll be generated. But if it does, tsc<\/code> will try to use that file to incrementally type-check and update our output files.<\/p>\n.tsbuildinfo<\/code> files can be safely deleted and don’t have any impact on our code at runtime – they’re purely used to make compilations faster. We can also name them anything that we want, and place them anywhere we want using the --tsBuildInfoFile<\/code> flag.<\/p>\n\/\/ front-end.tsconfig.json<\/span>\r\n{\r\n \"<\/span>compilerOptions\"<\/span><\/span>:<\/span> {\r\n \"<\/span>incremental\"<\/span><\/span>:<\/span> true<\/span>,\r\n \"<\/span>tsBuildInfoFile\"<\/span><\/span>:<\/span> \"<\/span>.\/buildcache\/front-end\"<\/span><\/span>,\r\n \"<\/span>outDir\"<\/span><\/span>:<\/span> \"<\/span>.\/lib\"<\/span><\/span>\r\n },\r\n \"<\/span>include\"<\/span><\/span>:<\/span> [\"<\/span>.\/src\"<\/span><\/span>]\r\n}<\/pre>\n<\/div>\n<\/h3>\n
Composite projects<\/h3>\n
tsconfig.json<\/code>s with composite<\/code> set to true<\/code>) is that references between different projects can be built incrementally. As such, composite projects will always<\/strong> produce .tsbuildinfo<\/code> files.<\/p>\n<\/h3>\n
outFile<\/code><\/h3>\noutFile<\/code> is used, the build information file’s name will be based on the output file’s name. As an example, if our output JavaScript file is .\/output\/foo.js<\/code>, then under the --incremental<\/code> flag, TypeScript will generate the file .\/output\/foo.tsbuildinfo<\/code>. As above, this can be controlled with the --tsBuildInfoFile<\/code> flag.<\/p>\n<\/h3>\n
The
--incremental<\/code> file format and versioning<\/h3>\n--incremental<\/code> is JSON, the file isn’t mean to be consumed by any other tool. We can’t provide any guarantees of stability for its contents, and in fact, our current policy is that any one version of TypeScript will not understand .tsbuildinfo<\/code> files generated from another version.<\/p>\n<\/h2>\n
Improvements for
ReadonlyArray<\/code> and readonly<\/code> tuples<\/h2>\n<\/h3>\n
A new syntax for
ReadonlyArray<\/code><\/h3>\nReadonlyArray<\/code> type describes Array<\/code>s that can only be read from. Any variable with a handle to a ReadonlyArray<\/code> can’t add, remove, or replace any elements of the array.<\/p>\nfunction<\/span> foo(arr<\/span>:<\/span> ReadonlyArray<\/span><string<\/span>>) {\r\n arr<\/span>.slice<\/span>(); \/\/ okay<\/span>\r\n arr<\/span>.push<\/span>(\"<\/span>hello!\"<\/span><\/span>); \/\/ error!<\/span>\r\n}<\/pre>\n<\/div>\nReadonlyArray<\/code> over Array<\/code> for the purpose of intent, it’s often been a pain given that arrays have a nicer syntax. Specifically, number[]<\/code> is a shorthand version of Array<number><\/code>, just as Date[]<\/code> is a shorthand for Array<Date><\/code>.<\/p>\nReadonlyArray<\/code> using a new readonly<\/code> modifier for array types.<\/p>\nfunction<\/span> foo(arr<\/span>:<\/span> readonly<\/span> string<\/span>[]) {\r\n arr<\/span>.slice<\/span>(); \/\/ okay<\/span>\r\n arr<\/span>.push<\/span>(\"<\/span>hello!\"<\/span><\/span>); \/\/ error!<\/span>\r\n}<\/pre>\n<\/div>\n<\/h3>\n
readonly<\/code> tuples<\/h3>\nreadonly<\/code> tuples. We can prefix any tuple type with the readonly<\/code> keyword to make it a readonly<\/code> tuple, much like we now can with array shorthand syntax. As you might expect, unlike ordinary tuples whose slots could be written to, readonly<\/code> tuples only permit reading from those positions.<\/p>\nfunction<\/span> foo(pair<\/span>:<\/span> readonly<\/span> [string<\/span>, string<\/span>]) {\r\n console<\/span>.log<\/span>(pair<\/span>[0<\/span>]); \/\/ okay<\/span>\r\n pair<\/span>[1<\/span>] =<\/span> \"<\/span>hello!\"<\/span><\/span>; \/\/ error<\/span>\r\n}<\/pre>\n<\/div>\nArray<\/code> – a tuple with elements of type T<\/code>1<\/code><\/sub>, T<\/code>2<\/code><\/sub>, … T<\/code>n<\/code><\/sub> extends from Array<<\/code> T<\/code>1<\/code><\/sub> | T<\/code>2<\/code><\/sub> | … T<\/code>n<\/code><\/sub> ><\/code> – readonly<\/code> tuples are types that extend from ReadonlyArray<\/code>. So a readonly<\/code> tuple with elements T<\/code>1<\/code><\/sub>, T<\/code>2<\/code><\/sub>, … T<\/code>n<\/code><\/sub> extends from ReadonlyArray<<\/code> T<\/code>1<\/code><\/sub> | T<\/code>2<\/code><\/sub> | … T<\/code>n<\/code><\/sub> ><\/code>.<\/p>\n<\/h3>\n
readonly<\/code> mapped type modifiers and readonly<\/code> arrays<\/h3>\nBoxify<\/code> could work on arrays and tuples alike.<\/p>\ninterface<\/span> Box<\/span><T<\/span>> { value:<\/span> T<\/span> }\r\n\r\ntype<\/span> Boxify<\/span><T<\/span>> =<\/span> {\r\n [K<\/span>