Today we’re excited to announce our Release Candidate (RC) of TypeScript 4.5! Between now and the stable release of TypeScript 4.5, we expect no further changes apart from critical bug fixes.<\/p>\n
To get started using the RC, you can get it\u00a0through NuGet<\/a>, or use npm with the following command:<\/p>\n You can also get editor support by<\/p>\n If you’ve already read\u00a0our beta blog post<\/a>, you can\u00a0read up on what’s changed since<\/a>.<\/p>\n Some major highlights of TypeScript 4.5 are:<\/p>\n Since\u00a0our beta release post<\/a>, 4.5 has gone through a few changes.<\/p>\n The biggest change we’ve made since the beta is that\u00a0ECMAScript module support for Node.js 12 has been deferred<\/a>\u00a0to a future release, and is now only available as an experimental flag in nightly releases. This was not an easy decision, but our team had a combination of\u00a0concerns around ecosystem readiness and general guidance for how\/when to use the feature<\/a>. We felt it would be better to smooth out the user experience instead of releasing something that would ultimately be too frustrating for most people. In the meantime though, you can still use the new support for\u00a0 From the language editing side, we’ve introduced more snippet completions –\u00a0specifically, for method implementation and overrides<\/a>.<\/p>\n We’ve also\u00a0addressed a performance regression in\u00a0 For the last few years, Node.js has been working to support running ECMAScript modules (ESM). This has been a very difficult feature to support, since the foundation of the Node.js ecosystem is built on a different module system called CommonJS (CJS). Interoperating between the two brings large challenges, with many new features to juggle.<\/p>\n TypeScript 4.5 initially added new settings to support directly running ECMAScript modules in Node.js; however, we believe that the current experience needs more “bake time” before it can be used more broadly. You can see more details of why\u00a0here<\/a>.<\/p>\n In turn, this feature is still available for use, but\u00a0only under\u00a0nightly releases<\/a>\u00a0of TypeScript<\/strong>, and not in TypeScript 4.5.<\/p>\n We are looking to hear what you think so far, so if you’re interested in using TypeScript and running ECMAScript modules under Node.js,\u00a0read more about this feature in our documentation<\/a>,\u00a0try it out<\/a>, and give us your feedback!<\/p>\n To ensure that TypeScript and JavaScript support works well out of the box, TypeScript bundles a series of declaration files ( There are two occasional downsides to including these declaration files with TypeScript though:<\/p>\n TypeScript 4.5 introduces a way to override a specific built-in\u00a0 You can then use your package manager to install a specific package to take over for a given\u00a0 Then from 4.5 onwards, you can update TypeScript and your dependency manager’s lockfile will ensure that it uses the exact same version of the DOM types. That means you get to update your types on your own terms.<\/p>\n We’d like to give a shout-out to\u00a0saschanaz<\/a>\u00a0who has been extremely helpful and patient as we’ve been building out and experimenting with this feature.<\/p>\nnpm install typescript@rc<\/pre>\n<\/div>\n
\n
\n
lib<\/code>\u00a0from\u00a0node_modules<\/code><\/a><\/li>\nAwaited<\/code>\u00a0Type and\u00a0Promise<\/code>\u00a0Improvements<\/a><\/li>\n--module es2022<\/code><\/a><\/li>\ntype<\/code>\u00a0Modifiers on Import Names<\/a><\/li>\nrealPathSync.native<\/code><\/a><\/li>\nWhat’s New Since the Beta?<\/h2>\n
--module nodenext<\/code>\u00a0and\u00a0--moduleResolution nodenext<\/code>\u00a0as experimental features in\u00a0nightly builds of TypeScript<\/a>. If you try to use these settings in TypeScript 4.5 RC or stable, you’ll receive an error message directing you to use a nightly build instead.<\/p>\n--build<\/code>\u00a0mode<\/a>\u00a0due to excessive\u00a0realpath<\/code>\u00a0calls for\u00a0package.json<\/code>\u00a0files. This change was made for TypeScript 4.5, but was also back-ported to TypeScript 4.4.4. If this regression blocked you from trying TypeScript 4.4, you should see comparable or better speed in\u00a0--build<\/code>\u00a0mode compared to past versions.<\/p>\nExperimental Nightly-Only ECMAScript Module Support in Node.js<\/h2>\n
<\/a>Supporting\u00a0
lib<\/code>\u00a0from\u00a0node_modules<\/code><\/h2>\n.d.ts<\/code>\u00a0files). These declaration files represent the available APIs in the JavaScript language, and the standard browser DOM APIs. While there are some reasonable defaults based on your\u00a0target<\/code><\/a>, you can pick and choose which declaration files your program uses by configuring the\u00a0lib<\/code><\/a>\u00a0setting in the\u00a0tsconfig.json<\/code>.<\/p>\n\n
lib<\/code>\u00a0in a manner similar to how\u00a0@types\/<\/code>\u00a0support works. When deciding which\u00a0lib<\/code>\u00a0files TypeScript should include, it will first look for a scoped\u00a0@typescript\/lib-*<\/code>\u00a0package in\u00a0node_modules<\/code>. For example, when including\u00a0dom<\/code>\u00a0as an option in\u00a0lib<\/code>, TypeScript will use the types in\u00a0node_modules\/@typescript\/lib-dom<\/code>\u00a0if available.<\/p>\nlib<\/code>\u00a0For example, today TypeScript publishes versions of the DOM APIs on\u00a0@types\/web<\/code>. If you wanted to lock your project to a specific version of the DOM APIs, you could add this to your\u00a0package.json<\/code>:<\/p>\n{\r\n \"dependencies\"<\/span>: {\r\n \"@typescript\/lib-dom\"<\/span>: \"<\/span>npm:@types\/web\"<\/span><\/span>\r\n }\r\n}<\/pre>\n<\/div>\n