Today we’re proud to release TypeScript 3.8!<\/p>\n
For those unfamiliar with TypeScript, it’s a language that adds syntax for types on top of JavaScript which can be analyzed through a process called static type-checking<\/em>. This type-checking can tell us about errors like typos and values that are potentially If you’re already ready to use TypeScript, 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 TypeScript 3.8 brings a lot of new features, including new or upcoming ECMAScript standards features, new syntax for importing\/exporting only types, and more.<\/p>\n This feature is something most users may never have to think about; however, if you’ve hit issues here, it might be of interest (especially when compiling under TypeScript reuses JavaScript’s import syntax in order to let us reference types. For instance, in the following example, we’re able to import This is convenient because most of the time<\/em> we don’t have to worry about what’s being imported – just that we’re importing something<\/em>.<\/p>\n Unfortunately, this only worked because of a feature called import elision<\/em>. When TypeScript outputs JavaScript files, it sees that Again, this behavior is usually great, but it causes some other problems.<\/p>\n First of all, there are some places where it’s ambiguous whether a value or a type is being exported. For example, in the following example is Limiting ourselves to just this file, there’s no way to know. Both Babel and TypeScript’s The other issue was that TypeScript’s import elision would get rid of import statements that only<\/em> contained imports used as types. That caused observably different behavior for modules that have side-effects, and so users would have to insert a second<\/em> import statement purely to ensure side-effects.<\/p>\nnull<\/code> and undefined<\/code> before we even run our code. More than just that, that same type analysis can be used to provide a solid editing experience for both TypeScript and<\/em> JavaScript, powering operations like code completion, find-all-references, quick fixes, and refactorings. In fact, if you’re already using JavaScript in an editor like Visual Studio and Visual Studio Code, your editing experience is really being powered by TypeScript! So if you’re interested in learning more, head over to our website<\/a>.<\/p>\nnpm install typescript<\/pre>\n<\/div>\n
\n
\n
export * as ns<\/code> Syntax<\/a><\/li>\nawait<\/code><\/a><\/li>\nwatchOptions<\/code><\/a><\/li>\n\n
Type-Only Imports and Exports<\/span><\/h2>\n
--isolatedModules<\/code>, our transpileModule<\/code> API, or Babel).<\/p>\ndoThing<\/code> which is a JavaScript value along with Options<\/code> which is purely a TypeScript type.<\/p>\n\/\/ .\/foo.ts<\/span>\r\ninterface<\/span> Options<\/span> {<\/span>\r\n \/\/ ...<\/span>\r\n}<\/span>\r\n\r\nexport<\/span> function<\/span> doThing<\/span>(<\/span>options<\/span>: Options<\/span>)<\/span> {<\/span>\r\n \/\/ ...<\/span>\r\n}<\/span>\r\n\r\n\/\/ .\/bar.ts<\/span>\r\nimport<\/span> {<\/span> doThing<\/span>,<\/span> Options<\/span> }<\/span> from<\/span> \".\/foo.js\"<\/span>;<\/span>\r\n\r\nfunction<\/span> doThingBetter<\/span>(<\/span>options<\/span>: Options<\/span>)<\/span> {<\/span>\r\n \/\/ do something twice as good<\/span>\r\n doThing<\/span>(<\/span>options<\/span>)<\/span>;<\/span>\r\n doThing<\/span>(<\/span>options<\/span>)<\/span>;<\/span>\r\n}<\/span><\/pre>\n<\/div>\nOptions<\/code> is only used as a type, and it automatically drops its import. The resulting output looks kind of like this:<\/p>\n\/\/ .\/foo.js<\/span>\r\nexport<\/span> function<\/span> doThing<\/span>(<\/span>options<\/span>: Options<\/span>)<\/span> {<\/span>\r\n \/\/ ...<\/span>\r\n}<\/span>\r\n\r\n\/\/ .\/bar.js<\/span>\r\nimport<\/span> {<\/span> doThing<\/span> }<\/span> from<\/span> \".\/foo.js\"<\/span>;<\/span>\r\n\r\nfunction<\/span> doThingBetter<\/span>(<\/span>options<\/span>: Options<\/span>)<\/span> {<\/span>\r\n \/\/ do something twice as good<\/span>\r\n doThing<\/span>(<\/span>options<\/span>)<\/span>;<\/span>\r\n doThing<\/span>(<\/span>options<\/span>)<\/span>;<\/span>\r\n}<\/span><\/pre>\n<\/div>\nMyThing<\/code> a value or a type?<\/p>\nimport<\/span> {<\/span> MyThing<\/span> }<\/span> from<\/span> \".\/some-module.js\"<\/span>;<\/span>\r\n\r\nexport<\/span> {<\/span> MyThing<\/span> }<\/span>;<\/span><\/pre>\n<\/div>\ntranspileModule<\/code> API will emit code that doesn’t work correctly if MyThing<\/code> is only a type, and TypeScript’s isolatedModules<\/code> flag will warn us that it’ll be a problem. The real problem here is that there’s no way to say “no, no, I really only meant the type – this should be erased”, so import elision isn’t good enough.<\/p>\n\/\/ This statement will get erased because of import elision.<\/span>\r\nimport<\/span> {<\/span> SomeTypeFoo<\/span>,<\/span> SomeOtherTypeBar<\/span> }<\/span> from<\/span> \".\/module-with-side-effects\"<\/span>;<\/span>\r\n\r\n\/\/ This statement always sticks around.<\/span>\r\nimport<\/span> \".\/module-with-side-effects\"<\/span>;<\/span><\/pre>\n<\/div>\n