Today we’re excited to announce our Release Candidate (RC) of TypeScript 4.3! Between now and the stable release of TypeScript 4.3, 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 Let’s dive in to what TypeScript 4.3 brings!<\/p>\n In JavaScript, it’s pretty common for APIs to convert values that are passed in before storing them. This often happens with getters and setters too. For example, let’s imagine we’ve got a class with a setter that always converts a value into a\u00a0 How would we type this JavaScript code in TypeScript? Well, technically we don’t have to do anything special here – TypeScript can look at this with no explicit types and can figure out that\u00a0 The problem is that\u00a0 But that’s no good –\u00a0 That’s why TypeScript 4.3 allows you to specify types for reading and writing to properties.<\/p>\n In the above example, our\u00a0npm install typescript@rc<\/pre>\n<\/div>\n
\n
\n
override<\/code>\u00a0and the\u00a0--noImplicitOverride<\/code>\u00a0Flag<\/a><\/li>\n#private<\/code>\u00a0Class Elements<\/a><\/li>\nConstructorParameters<\/code>\u00a0Works on Abstract Classes<\/a><\/li>\nstatic<\/code>\u00a0Index Signatures<\/a><\/li>\n.tsbuildinfo<\/code>\u00a0Size Improvements<\/a><\/li>\n--incremental<\/code>\u00a0and\u00a0--watch<\/code>\u00a0Compilations<\/a><\/li>\n@link<\/code>\u00a0Tags<\/a><\/li>\n<\/a>Separate Write Types on Properties<\/h2>\n
number<\/code>\u00a0before saving it in a private field.<\/p>\nclass<\/span> Thing<\/span> {<\/span>\r\n #size<\/span> =<\/span> 0<\/span>;<\/span>\r\n\r\n get<\/span> size<\/span>(<\/span>)<\/span> {<\/span>\r\n return<\/span> this<\/span>.<\/span>#size<\/span>;<\/span>\r\n }<\/span>\r\n set<\/span> size<\/span>(<\/span>value<\/span>)<\/span> {<\/span>\r\n let<\/span> num<\/span> =<\/span> Number<\/span>(<\/span>value<\/span>)<\/span>;<\/span>\r\n\r\n \/\/ Don't allow NaN and stuff.<\/span>\r\n if<\/span> (<\/span>!<\/span>Number<\/span>.<\/span>isFinite<\/span>(<\/span>num<\/span>)<\/span>)<\/span> {<\/span>\r\n this<\/span>.<\/span>#size<\/span> =<\/span> 0<\/span>;<\/span>\r\n return<\/span>;<\/span>\r\n }<\/span>\r\n\r\n this<\/span>.<\/span>#size<\/span> =<\/span> num<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nsize<\/code>\u00a0is a number.<\/p>\nsize<\/code>\u00a0allows you to assign more than just\u00a0number<\/code>s to it. We could get around this by saying that\u00a0size<\/code>\u00a0has the type\u00a0unknown<\/code>\u00a0or\u00a0any<\/code>\u00a0like in this snippet:<\/p>\nclass<\/span> Thing<\/span> {<\/span>\r\n \/\/ ...<\/span>\r\n get<\/span> size<\/span>(<\/span>)<\/span>: unknown<\/span> {<\/span>\r\n return<\/span> this<\/span>.<\/span>#size<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nunknown<\/code>\u00a0forces people reading\u00a0size<\/code>\u00a0to do a type assertion, and\u00a0any<\/code>\u00a0won’t catch any mistakes. If we really want to model APIs that convert values, previous versions of TypeScript forced us to pick between being precise (which makes reading values easier, and writing harder) and being permissive (which makes writing values easier, and reading harder).<\/p>\nclass<\/span> Thing<\/span> {<\/span>\r\n #size<\/span> =<\/span> 0<\/span>;<\/span>\r\n\r\n get<\/span> size<\/span>(<\/span>)<\/span>: number<\/span> {<\/span>\r\n return<\/span> this<\/span>.<\/span>#size<\/span>;<\/span>\r\n }<\/span>\r\n\r\n set<\/span> size<\/span>(<\/span>value<\/span>: string<\/span> |<\/span> number<\/span> |<\/span> boolean<\/span>)<\/span> {<\/span>\r\n let<\/span> num<\/span> =<\/span> Number<\/span>(<\/span>value<\/span>)<\/span>;<\/span>\r\n\r\n \/\/ Don't allow NaN and stuff.<\/span>\r\n if<\/span> (<\/span>!<\/span>Number<\/span>.<\/span>isFinite<\/span>(<\/span>num<\/span>)<\/span>)<\/span> {<\/span>\r\n this<\/span>.<\/span>#size<\/span> =<\/span> 0<\/span>;<\/span>\r\n return<\/span>;<\/span>\r\n }<\/span>\r\n\r\n this<\/span>.<\/span>#size<\/span> =<\/span> num<\/span>;<\/span>\r\n }<\/span>\r\n}<\/span><\/pre>\n<\/div>\nset<\/code>\u00a0accessor takes a broader set of types (string<\/code>s,\u00a0boolean<\/code>s, and\u00a0number<\/code>s), but our\u00a0get<\/code>\u00a0accessor always guarantees it will be a\u00a0number<\/code>. Now we can finally assign other types to these properties with no errors!<\/p>\nlet<\/span> thing<\/span> =<\/span> new<\/span> Thing<\/span>(<\/span>)<\/span>;<\/span>\r\n\r\n\/\/ Assigning other types to `thing.size` works!<\/span>\r\nthing<\/span>.<\/span>size<\/span> =<\/span> \"hello\"<\/span>;<\/span>\r\nthing<\/span>.<\/span>size<\/span> =<\/span> true<\/span>;<\/span>\r\nthing<\/span>.<\/span>size<\/span> =<\/span> 42<\/span>;<\/span>\r\n\r\n\/\/ Reading `thing.size` always produces a number!<\/span>\r\nlet<\/span> mySize<\/span>: