Hacker News new | past | comments | ask | show | jobs | submit login
TypeScript 4.0 Beta (microsoft.com)
94 points by DanRosenwasser 14 days ago | hide | past | favorite | 17 comments

Looks like some improvements to spread operators and tuples, which is welcome.

I'm most excited about: TypeScript 4.0 supports a promising proposal to add three new assignment operators: &&=, ||=, and ??=.

Which is a nice shortcut for operators I use often.

No huge changes here that I can see, just small steady improvements to an already excellent language.

Variadic tuple types are so good for library maintainers. Being able to spread your types is a huge delight. For a lot of situation, there will be no need for filling unnecessary overloads. And labels will make the code more readable for those.

Variadic tuples are a pretty big type system feature and will make some typing/library maintainers very happy.

I'm a bit paranoid about upgrading after breaking changes in 3.9 removed the ability to stub ES imports with Sinon/Jasmine/etc..., since the section of the release notes made it sound pretty innocuous: "Getters/Setters are No Longer Enumerable".

https://github.com/microsoft/TypeScript/issues/38568 https://github.com/microsoft/TypeScript/pull/32264

That’s the same behavior as Babel no ?

I have no idea, I don't have experience with Babel. As mentioned in the release notes, this change makes TS conform more closely to ECMAScript, so I don't think it's a bad decision. But it would've been nice to get some warning or error when trying to stub an ES import, rather than the silent failures

Have you found a way around that change? It’s blocked me from upgrading as well.

This release will be great. Lots of people were waiting for variadic tuple types.

I love when such "old" feature request is finally added to Typescript. First proposal for it was almost 5 years ago [1]. It really gives hope for other long standing and heavily upvoded feature requests that maybe we'll get them one day :)


So excited for variadic tuple types. This will be an absolute game changer!

> Properties Overriding Accessors (and vice versa) is an Error

Not sure I like this. Can definitely imagine the following being a realistic scenario, and see no reason to disallow it:

    class Base {
      public num = 42;

    class Child extends Base {
      protected _num = 42;
      // no longer allowed in 4.0
      public get num() { return this._num; }
      public set num(newVal) { 
        alert(`new num ${newVal}`);
        this._num = newVal
Did I misunderstand something?

I think this error only happen if you don't provide both a getter and setter in the case where the class you're extending uses an instance property. Or if your extended class uses an instance property where the class it is extending only provided a getter.

Ah. Okay. That would be fair.

—incremental with —noEmit is kind of a big deal. Really cool.

We use ts-loader with webpack in transpileOnly mode and a separate tsc invocation for typechecking that runs as a linter i.e noEmit

I like TypeScript because it gives me an edge over my competitors. I look forward to Microsoft coming up with more abstractions to further constrain and slow down my competition and keep lowering the productivity bar in my industry - Microsoft was right when they said that TypeScript would make my life easier.

you are sarcastic, but what i noticed is that languages on top of javascript improve the hiring pool.

i already experienced that earlier with coffeescript.

because javascript is so ubiquitous, everyone has to learn it, and there is a large pool of inexperienced javascript developers.

however, only those who are actually skilled will apply for a position that requires coffeescript or typescript.

I think this is only because tech hiring is broken and has been broken for decades.

You forgot the /s

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact