{"id":1045,"date":"2017-04-27T16:05:52","date_gmt":"2017-04-27T16:05:52","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1045"},"modified":"2019-02-20T10:45:53","modified_gmt":"2019-02-20T17:45:53","slug":"announcing-typescript-2-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-3\/","title":{"rendered":"Announcing TypeScript 2.3"},"content":{"rendered":"
\n

Today we’re excited to bring you our latest release with TypeScript 2.3!<\/p>\n

For those who aren’t familiar, TypeScript is a superset of JavaScript that brings users optional static types and solid tooling. Using TypeScript can help avoid painful bugs people commonly run into when writing JavaScript by type-checking your code. TypeScript can actually report issues without you even saving your file, and leverage the type system to help you write code even faster. This leads to a truly awesome editing experience, giving you time to think about and test the things that really matter.<\/p>\n

To get started with the latest stable version of TypeScript, you can grab it through NuGet<\/a>, or use the following command with npm:<\/p>\n

\n
npm install -g typescript<\/pre>\n<\/div>\n
Visual Studio 2015 users (who have Update 3<\/a>) as well as<\/em> Visual Studio 2017 users using Update 2 Preview<\/a> will be able to get TypeScript by simply installing it from here<\/a>. To elaborate a bit, this also means that Visual Studio 2017 Update 2 will be able to use any newer version of TypeScript side-by-side with older ones<\/a>.<\/p>\n
For other editors, default support for 2.3 should be coming soon, but you can configure Visual Studio Code<\/a> and our Sublime Text plugin<\/a> to pick up whatever version you need.<\/p>\n
While our What’s New in TypeScript<\/a> Page will give the full scoop, let’s dive in to see some of the great new features TypeScript 2.3 brings!<\/p>\n
Type checking in JavaScript files with \/\/ @ts-check<\/code> and --checkJs<\/code><\/h2>\n
TypeScript has long had an option for gradually migrating your files from JavaScript to TypeScript using the --allowJs<\/code> flag; however, one of the common pain-points we heard from JavaScript users was that migrating JavaScript codebases and getting early benefits from TypeScript was difficult. That’s why in TypeScript 2.3, we’re experimenting with a new “soft” form of checking in .js<\/code> files, which brings many of the advantages of writing TypeScript without actually writing .ts<\/code> files.<\/p>\n
This new checking mode uses comments<\/a> to specify types on regular JavaScript declarations. Just like in TypeScript, these annotations are completely optional<\/em>, and inference will usually pick up the slack from there. But in this mode, your code is still runnable and doesn’t need to go through any new transformations.<\/p>\n
You can try this all out without even needing to touch your current build tools. If you’ve already got TypeScript installed (npm install -g typescript<\/code>), getting started is easy! First create a tsconfig.json<\/code> in your project’s root directory:<\/p>\n
\n
{\n    \"<\/span>compilerOptions\"<\/span><\/span>: {\n        \"<\/span>noEmit\"<\/span><\/span>: true<\/span>,\n        \"<\/span>allowJs\"<\/span><\/span>: true<\/span>\n    },\n    \"<\/span>include\"<\/span><\/span>: [\n        \"<\/span>.\/src\/\"<\/span><\/span>\n    ]\n}<\/pre>\n<\/div>\n
Note: We’re assuming our files are in src<\/code>. Your folder names might be different.<\/p><\/blockquote>\n
Now all you need to do to type-check a file is to add a comment with \/\/ @ts-check<\/code> to the top. Now run tsc<\/code> from the same folder as your tsconfig.json<\/code> and that’s it<\/strong>.<\/p>\n
\n
\/\/ @ts-check<\/span>\n\n\/**<\/span>\n * @param<\/span> {string}<\/span> input<\/span><\/span>\n *\/<\/span>\nfunction<\/span> foo<\/span>(input<\/span>) {\n    input<\/span>.tolowercase<\/span>()\n    \/\/    ~~~~~~~~~~~ Error! Should be toLowerCase<\/span>\n}<\/pre>\n<\/div>\n
We just assumed you didn’t want to bring TypeScript into your build pipeline at all, but TypeScript is very flexible about how you want to set up your project. Maybe you wanted to have all<\/em> JavaScript files in your project checked with the checkJs<\/code> flag instead of using \/\/ @ts-check<\/code> comments. Maybe you wanted TypeScript to also compile down your ES2015+ code while checking it. Here’s a tsconfig.json<\/code> that does just that:<\/p>\n
\n
{\n    \"<\/span>compilerOptions\"<\/span><\/span>: {\n        \"<\/span>target\"<\/span><\/span>: \"<\/span>es5\"<\/span><\/span>,\n        \"<\/span>module\"<\/span><\/span>: \"<\/span>commonjs\"<\/span><\/span>,\n        \"<\/span>allowJs\"<\/span><\/span>: true<\/span>,\n        \"<\/span>checkJs\"<\/span><\/span>: true<\/span>,\n        \"<\/span>outDir\"<\/span><\/span>: \"<\/span>.\/lib\"<\/span><\/span>\n    },\n    \"<\/span>include\"<\/span><\/span>: [\n        \"<\/span>.\/src\/**\/*\"<\/span><\/span>\n    ]\n}<\/pre>\n<\/div>\n
Note: Since TypeScript is creating new files, we had to set outDir<\/code> to another folder like lib<\/code>. That might not be necessary if you use tools like Webpack, Gulp, etc.<\/span><\/p><\/blockquote>\n
Next, you can start using TypeScript declaration files (.d.ts<\/code> files)<\/a> for any of your favorite libraries and benefit from any new code you start writing. We think you’ll be especially happy getting code completion and error checking based on these definitions, and chances are, you may’ve already tried it<\/a>.<\/p>\n
This JavaScript checking mode also allows for two other comments in .js<\/code> files:<\/p>\n
    \n
  1. \/\/ @ts-nocheck<\/code> to disable a file from being checked when --checkJs<\/code> is on<\/li>\n
  2. \/\/ @ts-ignore<\/code> to ignore errors on the following line.<\/li>\n<\/ol>\n
    You might already be thinking of this experience as something similar to linting; however, that doesn’t mean we’re trying to replace your linter! We see this as something complementary that can run side-by-side with existing tools like ESLint<\/a> on your JavaScript. Each tool can play to its strengths.<\/p>\n
    If you’re already using TypeScript, we’re sure you have a JavaScript codebase lying around you can turn this on to quickly catch some real bugs in. But if you’re new to TypeScript, we think that this mode will really help show you what TypeScript has to offer without needing to jump straight in or commit.<\/p>\n
    Language server plugin support<\/h2>\n
    One of TypeScript’s goals is to deliver a state-of-the-art editing experience to the JavaScript world. This experience is something our users have long enjoyed, whether it came to using traditional JavaScript constructs, newer ECMAScript features, or even JSX.<\/p>\n
    However, in the spirit of separation of concerns, TypeScript avoided special-casing certain content such as templates. This was a problem that we’d discussed deeply with the Angular team – we wanted to be able to deliver the same level of tooling to Angular users for their templates as we did in other parts of their code. That included completions, go-to-definition, error reporting, etc.<\/p>\n
    After working closely with the Angular team, we’re happy to announce that TypeScript 2.3 officially makes a language server plugin API available. This API allows plugins to augment the regular editing experience that TypeScript already delivers. What all of this means is that you can get an enhanced editing experience for many different workloads.<\/p>\n
    You can see the progress of Angular’s Visual Studio Code Plugin here<\/a> which can greatly enhance the experience for Angular users. But importantly, note here is that this is a general<\/em> API – that means that a plugin can be written for many different types of content. As an example, there’s already<\/em> a TSLint<\/a> language server plugin, as well as a TypeScript GraphQL language server plugin<\/a>! The Vetur plugin<\/a> has also delivered a better TypeScript and JavaScript editing experience within .vue<\/code> files for Vue.js through our language server plugin model.<\/p>\n
    We hope that TypeScript will continue to empower users of different toolsets. If you’re interested in providing an enhanced experience for your users, you can check out this example plugin<\/a>.<\/p>\n
    Default type arguments<\/h2>\n
    To explain this feature, let’s take a simplified look at React’s component API. A React component will have props<\/code> and potentially some state<\/code>. You could encode this like follows:<\/p>\n
    \n
    class<\/span> Component<\/span><P<\/span>, S<\/span>> {\n    \/\/ ...<\/span>\n}<\/pre>\n<\/div>\n
    Here P<\/code> is the type of props<\/code> and S<\/code> is the type of state<\/code>.<\/p>\n
    However, much of the time, state<\/code> is never used in a component. In those cases, we can just write the type as object<\/code> or {}<\/code>, but we have to do so explicitly:<\/p>\n
    \n
    class<\/span> FooComponent<\/span> extends<\/span> React<\/span>.Component<\/span><FooProps<\/span>, object<\/span>> {\n    \/\/ ...<\/span>\n}<\/pre>\n<\/div>\n
    This may not be surprising. It’s fairly common for APIs to have some concept of default values for information you don’t care about.<\/p>\n
    Enter default type arguments. Default type arguments allow us to free ourselves from thinking of unused generics. In TypeScript 2.3, we can declare React.Component<\/code> as follows:<\/p>\n
    \n
    class<\/span> Component<\/span><P<\/span>, S<\/span> = object<\/span>> {\n    \/\/ ...<\/span>\n}<\/pre>\n<\/div>\n
    And now whenever we write Component<FooProps><\/code>, we’re implicitly writing Component<FooProps, object><\/code>.<\/p>\n
    Keep in mind that a type parameter’s default isn’t necessarily the same as its constraint (though the default has to be assignable to the constraint).<\/p>\n
    Generator and async generator support<\/h2>\n
    Previously, TypeScript didn’t support compiling generators or working with iterators. With TypeScript 2.3, it not only supports both, it also brings support for ECMAScript’s new async<\/em> generators and async<\/em> iterators.<\/p>\n
    This is an opt-in feature when using the --downlevelIteration<\/code> flag. You can read more about this on our RC blog post<\/a>.<\/p>\n
    This functionality means TypeScript more thoroughly supports the latest version of ECMAScript when targeting older versions. It also means that TypeScript can now work well with libraries like redux-saga<\/a>.<\/p>\n
    Easier startup with better help, richer init, and quicker strictness<\/h2>\n
    Another one of the common pain-points we heard from our users was around the difficulty of getting started in general, and of the discoverability of new options. We had found that people were often unaware that TypeScript could work on JavaScript files, or that it could catch nullability errors. We wanted to make TypeScript more approachable, easier to explore, and more helpful at getting you to the most ideal experience.<\/p>\n
    First, TypeScript’s --help<\/code> output has been improved so that options are grouped by their topics, and more involved\/less common options are skipped by default. To get a complete list of options, you can type in tsc --help --all<\/code>.<\/p>\n
    Second, because users are often unaware of the sorts of options that TypeScript does<\/em> make available, we’ve decided to take advantage of TypeScript’s --init<\/code> output so that potential options are explicitly listed out in comments. As an example, tsconfig.json<\/code> output will look something like the following:<\/p>\n
    \n
    {\n  \"<\/span>compilerOptions\"<\/span><\/span>: {\n    \/*  Basic  Options *\/<\/span>\n    \"target\"<\/span>: \"es5\"<\/span>,              \/* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. *\/<\/span>\n    \"module\"<\/span>: \"commonjs\"<\/span>,         \/* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. *\/<\/span>\n    \/\/ \"lib\": [],                 \/* Specify library files to be included in the compilation:  *\/<\/span>\n    \/\/ \"allowJs\": true,           \/* Allow javascript files to be compiled. *\/<\/span>\n    \/\/ \"checkJs\": true,           \/* Report errors in .js files. *\/<\/span>\n    \/\/ \"jsx\": \"preserve\",         \/* Specify JSX code generation: 'preserve', 'react-native', or 'react'. *\/<\/span>\n    \/\/ \"declaration\": true,       \/* Generates corresponding '.d.ts' file. *\/<\/span>\n    \/\/ \"sourceMap\": true,         \/* Generates corresponding '.map' file. *\/<\/span>\n    \/\/ ...<\/span>\n  }\n}<\/pre>\n<\/div>\n
    We believe that changing our --init<\/code> output will make it easier to make changes to your tsconfig.json<\/code> down the line, and will make it quicker to discover TypeScript’s capabilities.<\/p>\n
    Finally, we’ve added the --strict<\/code> flag, which enables the following settings<\/p>\n