
TypeScript 4.0 - macote
https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/
======
msoad
TypeScript versioning is a joke on Semver that Daniel and team love to play.
They go from 3.9 to 4.0 because as you all know 3.10 would be impossible!

Every version of TypeScript is potentially a breaking change so if they wanted
to be pure Semvers we would've been at TypeScript version 100 or more which
could make people feel overwhelmed about being behind with their current
version.

As always a great release! Congratulations to the team! We love TypeScript at
my team.

I've never seen someone who wants to go back from TypeScript to plain
JavaScript. Design decisions made about structural comparison and not much
focus on correctness made TypeScript an easy forgiving type system that hold
developer's hand without being a pain in the bottom. The way TypeScript
interacted with the community and received feedback also helped its success.

~~~
jiofih
You know, software projects are under no obligation to follow semver. I abhor
this newfound conformism in tech.

Plus, after nearly a decade of programming I can safely say the benefits of
semantic versioning rarely materialize. 99% of the time you just upgrade to
whatever latest is, major or not, and deal with it. For all I care they could
be releasing Typescript v736.8B

~~~
wonderlg
The difference is that I can update all dependencies without having to verify
whether they contain breaking changes, because I can just look at the number.

Conformism helps us think less. Imagine if every website had their own way of
scrolling or logging in. Press T to login. Triple click here.

Semver helps me update 10 dependencies in 5 seconds without opening any
release notes.

Developers are under no obligations, but one should not go out of their way to
make others’ lives harder. Just use semver.

~~~
Waterluvian
If you’re updating 10 dependencies in 5 seconds without really following along
closely what exactly you’re updating and why, maybe don’t do that.

~~~
diegof79
Not exactly 10 dependencies, but I do that many times by using version ranges
like ^1.0.0. So to answer your question: What you are updating and why...
mostly patch and minor versions that include vulnerability and performance
fixes. And I read release notes... but the number gives me a good idea what to
read in more detail.

Now the problem of TS not following the convention is that many projects have
ranges like ^3.7.1 in their package.json without knowing that a simple install
removing package-lock may break your build because 3.8 and 3.9 have breaking
changes in it.

------
jfengel
I'm disappointed that it still doesn't incorporate a tool for one common case,
runtime type checking. Node.js REST servers receive a lot of JSON objects and
it would be nice to automatically check that they actually follow type.

There are several aftermarket add-ons (io-ts, runtypes, class-validator) but
they all seem to impose extra steps or rewriting code -- and different
projects will use different ones. It seems like it should be something they
can build into the language. I'd rather have one good standard than a dozen
alternatives. (Can you guess I come from a Java background?)

~~~
jakelazaroff
That is outside of the scope of TypeScript, which is to be a statically typed
superset of JavaScript with no runtime cost.

It's easy enough to write a runtime type checking library; I wrote a tiny one
that I use in basically all my projects:
[https://npmjs.com/package/narrows](https://npmjs.com/package/narrows)

~~~
wonderlg
With your library one has to write types twice.

I understand that it’s not TypeScript’s job at the moment, but it’d be great
to enable runtime checks with the flick of a switch without typing extra code.

    
    
        function upper(s: string) {
          return s.toUpperCase();
        }
    

This function could have a nice implicit TypeError instead of “undefined is
not a function”

~~~
jakelazaroff
I’m not sure what you mean. My library has a `TypeOf` type that lets you
extract static type information from validation functions. And calling
`toUpperCase` on undefined _already_ results in a TypeError.

------
adamhearn
As a new developer, typescript is awesome for me. When developing for web,
there seems to be all sorts of “types” that I don’t get know or fully
understand. By forcing types, I can be sure the data I am passing is what I
want.

~~~
yboris
As a developer of many years, TypeScript is awesome for me ;)

It helps all of us so much! Thank you TypeScript team :D

------
globuous
I've been using reasonml lately and absolutely love it, I've been coding a non
trivial application, and there is essentially no type annotations (which makes
refactoring very easy). So I find it super weird when I read typescript code
because there are complexe type annotations with nested generics all over the
place.

Is it just that typescript needs these annotations whereas ocaml does not ? Or
it's just best practices that recommend still using them explicitly ?

------
nojvek
Typescript’s versions are just weird. I still don’t get why they don’t always
increase major versions if it’s a breaking change. Who cares if it’s
typescript 40 or typescript 4.0. You don’t need to be a special flake. It’s an
interface that lets you know when TS upgrades are safe and when they’ll break
your code. Sure most TS versions tighten the type system but there’s no harm
in having version 9000.

In the world of rust, cargo does a smart thing unlike npm I.e “Avoiding
Combinatorial explosion of dependencies. Cargo pulls back on npm’s model a
bit: it will unify dependencies up to semver compatibility”

If typescript were a rust package, it would break that assumption really bad.

Please follow semver like the rest of the npm ecosystem.

------
agustif
TypeScript 4.0

React 17

TypeGraphQL 1.0.0

GraphQL-Modules 1.0.0

StoryBook 6

Webpack 5

Next 9.5

It's been an awesome month for TS/GraphQL (stable) releases

~~~
topicseed
I missed Webpack 5 — going to look at it over the weekend! What are the
headline updates?

~~~
agustif
Well technically still on beta.

My main favourite is topLevelAwait experiment

