TypeScript 3.7

I just did some refactoring on a medium size code base and here are a few things to watch out for when adopting optional chaining and the new null coalescing operator:<p><pre><code> foo &amp;&amp; await foo(); </code></pre> is not the same as<p><pre><code> await foo?.(); </code></pre> this will work in most cases but subtly, the await wraps the undefined case into a Promise, while the original code would skip the await altogether.<p>String regular expression matching returns null, not undefined, so rewriting code such as:<p><pre><code> const match = str.match(&#x2F;reg(ex)&#x2F;); return match &amp;&amp; match[1]; </code></pre> is not the same thing as:<p><pre><code> return match?.[1]; </code></pre> because the latter returns undefined, not null, in case of match failure. This can cause problems if subsequent code expects null for match failure. An equivalent rewrite would be:<p><pre><code> return match?.[1] ?? null; </code></pre> which is longer than the original and arguably less clear.<p>A common idiom to catch and ignore exceptions can interact poorly with optional chaining:<p><pre><code> const v = await foo().catch(_ =&gt; {}); return v?.field; &#x2F;&#x2F; property &#x27;field&#x27; does not exist on type &#x27;void&#x27; </code></pre> This can be easily remedied by changing the first line to:<p><pre><code> const v = await foo().catch(_ =&gt; undefined); </code></pre> Of course, these new operators are very welcome and will greatly simplify and help increase the safety of much existing code. But as in all things syntax, being judicious about usage of these operators is important to maximize clarity.

I&#x27;m a big fan of the new operators.<p>One of my remaining gripes with Javascript&#x2F;Typescript is the try&#x2F;catch mess around await. It makes assignment of const a pain for async calls that may reject.<p>e.g.<p><pre><code> let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } &#x2F;&#x2F; at this point result is `SomeType | undefined` if (result) { doSomething(result); } </code></pre> I really want some kind of structures that allow me to make `result` constant. In some cases I&#x27;ve rolled my own Maybe&#x2F;Either wrapper and then move the try&#x2F;await&#x2F;catch into a function but that is still a pain.<p>This is such a common pattern in my code ... I wish there was a more elegant way to deal with it.

I really like the optional chaining operator for statically typed languages. Especially in TypeScript where you have the nullabilaty information baked into the type system.<p>However, in JS itself, it might cause developers to lose track of what can be null&#x2F;undefined in their code. In case they start to &quot;fix&quot; stuff by throwing in some &quot;?.&quot; because they don&#x27;t know better, the code maintainability will degrade a lot.<p>Maybe I&#x27;m just pessimistic. Let&#x27;s see how it will perform in the field!

Optional Chaining also coming soon to create-react-app, planned for v3.3 (current release is react-scripts@3.2.0) - <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;create-react-app&#x2F;pull&#x2F;7438" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;create-react-app&#x2F;pull&#x2F;7438</a><p>I think they&#x27;re just waiting on support for the new syntax in prettier.

I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.

now if they can just add a compiler flag for &quot;immutable by default&quot;:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;32758" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;issues&#x2F;32758</a>

I feel really excited about 3.7. Optional chaining and null coalescing will clean up a TON of code.<p>... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.

The optional chaining and null coalescing operators are very nice. Dart has had those for several years and they really do come in handy.

The preview release announcement for this version made FP on HN already, but it&#x27;s a biggie:<p>* Optional Chaining &amp; Coalescing<p>* Assertion Functions<p>* .d.ts Emit From .js Files<p>* Smarter Control Flow Analysis<p>* Flatter Error Messages<p>also great:<p>* Function Truthy Checks &#x2F; Uncalled Function Checks (which was tslint&#x27;s biggest value prop for me up until now)

What&#x27;s the end state for TypeScript? Does it one day become feature complete and slow down? One of the frustrating things about trying to find help with TS today as a beginner is the plethora of SO and blog posts talking about much older versions. If you&#x27;re lucky there&#x27;ll be some comment &quot;As of 2.6 you can now do ...&quot;, but even 2.6 is a lot of versions back - how do I know that&#x27;s still the best way to do it in 3.7?<p>I&#x27;m for progress, but it makes me a little wary to start my team of no-previous-TS-experience JS devs on a TypeScript project when there&#x27;s still a new version every few months. Keeping up with Webpack is enough of a hassle...

Great incremental release.<p>Typescript really isn&#x27;t the most exciting language, but it&#x27;s very very helpful. Compared to regular javascript it saves me a lot of time, and so many pains and headaches every day.

Does the function argument (i.e. the template string) get evaluated regardless of the optional chaining or does it match up with the “roughly equivalent” code?<p><pre><code> log?.(`Request started at ${new Date().toISOString()}`); &#x2F;&#x2F; roughly equivalent to &#x2F;&#x2F; if (log != null) { &#x2F;&#x2F; log(`Request started at ${new Date().toISOString()}`); &#x2F;&#x2F; }</code></pre>

I&#x27;m super excited about this release, but it got off to a rocky start for me. Prior to 3.7, all our tests worked fine, but something in 3.7 changed that caused the type-checker to fail previously valid code. What&#x27;s worse is that I can&#x27;t reproduce the issue in a playground. Thankfully the workaround is &quot;make your code more explicit&quot;, which is fine, but it was just a surprise to see something like this break.<p>For those that are curious, here&#x27;s the error that 3.7 introduced:<p><pre><code> Type &#x27;SinonStub&lt;[string, RequestBody, (RequestOptions | undefined)?], KintoRequest&gt;&#x27; is not assignable to type &#x27;SinonStub&lt;any[], any&gt;&#x27;. Type &#x27;any[]&#x27; is missing the following properties from type &#x27;[string, RequestBody, (RequestOptions | undefined)?]&#x27;: 0, 1 </code></pre> I think the issue here is that `[string, RequestBody, (RequestOptions | undefined)?]` is a tuple type, and `any[]` is an array type. That being said though, I&#x27;d expect that a tuple would satisfy a `any[]` type.

Now I know how people felt when they told me C# was adding features so quickly they couldn&#x27;t keep up.

There&#x27;s a bunch of website work that came out with this release too: mainly search and a lot of playground improvements.<p><a href="https:&#x2F;&#x2F;www.typescriptlang.org" rel="nofollow">https:&#x2F;&#x2F;www.typescriptlang.org</a>

For this code:<p><pre><code> const x = [1,2]; const y = x[666]; const z = y + 3; </code></pre> Is there a way for TypeScript to flag the last line as a type error?<p>TypeScript will say &quot;y&quot; has type &quot;number&quot; when &quot;x[666]&quot; returns undefined. Why does TypeScript not say the type of &quot;y&quot; is &quot;number | undefined&quot;?

Very cool features for writing shorter code! I also noticed a small mistake in their examples: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript-Handbook&#x2F;issues&#x2F;1135" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript-Handbook&#x2F;issues&#x2F;1135</a>

This is going to be one of my favorite releases since 2.8, which added conditional types. So many bad utility functions will be able to go away. The only thing it seems to be missing is variadic type generics.

Optionals! I wrote Swift before typescript, and I&#x27;m a huge fan of these new operators.

From the snippets in the release notes:<p>```<p>function dispatch(x: string | number): SomeType {<p><pre><code> if (typeof x === &quot;string&quot;) { return doThingWithString(x); } else if (typeof x === &quot;number&quot;) { return doThingWithNumber(x); } process.exit(1); </code></pre> }<p>```<p>It&#x27;s very embarrassing in my opinion that they haven&#x27;t done anything yet against having these horrible kind of type checking; comparing against a string that has the type name? &quot;string&quot;, &quot;number&quot;? it&#x27;s completely ludicrous.<p>I will not take this language seriously until this is fixed. (For sure it&#x27;s still better than JavaScript, but that&#x27;s about it.)