
TypeScript 2.9 is now available - hamstercat
http://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html
======
camgunz
Hey I've been enjoying working with TypeScript lately, but when is this bug
gonna be fixed:
[https://github.com/Microsoft/TypeScript/issues/11375](https://github.com/Microsoft/TypeScript/issues/11375).

You basically can't implement iterators while using `strictNullChecks`, and
it's been broken since at least October 2016 (!)

Every time I go to use TS for a personal project I check to see if this is
fixed, and for almost two years the answer is no. I am dying here. Should I
not be implementing iterators? Does no one use `strictNullChecks`?

~~~
nitinreddy88
I am assuming you are developer of Js/TS, and being open source your
contribution to fix would be welcomed.

We expect contributions from everyone thats the motive behind OpenSource And
not just being transparent of code

~~~
maxilulu
He might be just a consumer not a compiler expert.

~~~
qop
I have seen the remark you're replying to hundreds of times throughout my
career. I've seen probably thousands of complaints about out-of-date exploits
or bad kits or including new injections and so on... This isn't infosec, but
it IS still FOSS.

I've always considered the reminder that open source loves contributions to be
a gentle reminder that:

* Most FOSS isn't sponsored.

* Most FOSS developers/maintainers aren't treated with much courtesy when things go wrong. "you broke my build!" etc.

* Without FOSS, a vibrant, interesting world would not exist within our computers, and even though its easy to forget, that world requires a rather significant amount of work for it to turn.

Ofc not everyone is a compiler expert. But everybody can help, and certainly
everybody can TRY to help. Framing an issue like this with "hey, I'm not a
compiler expert but there's this bug and I would love for it to be fixed, I
wouldn't even know where to start... It's an older bug, what's the plan?" is
much more courteous of the maintainers than "this shit is broke why don't u
fix it?!"

I'm exaggerating just to illustrate the spectrum. Better and worse examples
can be found all across the fossverse. Hell in just the Linux kernel alone
there's a whole village of different personalities.

My point to all this: it's a very common remark, goes back ages, and I think
it's a fantastic denominator to remind people the logistics of foss and human
beings.

Sorry to hijack your comment!

~~~
camgunz
Hey FWIW I'm aware I'm more or less trying to hijack a release thread with my
gripe. I don't think this should be standard practice for FOSS. In my defense
though, I waited for years on this bug, I like TypeScript, I want to use it
and evangelize it, and this (pretty fundamental) bug has languished meanwhile
we got... module types? I'm pretty sure 99.9999% of devs will never use those.
I bet they use iterators though.

Also I already have a job, and TypeScript is a Microsoft product with many
Microsoft engineers working on it every day. Let's not portray it as entirely
the altruism of some saintly engineers donating their time. We're not talking
about OpenBSD here.

~~~
mattbierner
Always remember this: you have different priorities than other users, than
other contributors, and than the core team. I for example find import types
useful for lazy loading modules, while I’ve never run into this bug in years
of writing TS.

If there is a bug or feature that really matters to you and that you feel is
not being prioritized:

\- Contribute a fix

\- Convince someone to contribute a fix

\- Complain enough that someone contributes a fix (which shouldn’t work but
sadly often does)

Otherwise it will be fixed when it is fixed.

(I am biased because I work with the TS team. However this is just general
open source stuff, I’m not speaking professionally)

~~~
camgunz
Sure, that's good advice. But all that stuff already happened here except for
"complain enough".

Also I didn't realize lazy loading was a common need. Does that mean that
awkward syntax is going to be everywhere? Surely there's a better way to get
that, like with an import lazy keyword. Really anything would be better.

~~~
WorldMaker
The `import<TModule>(url: string): Promise<TModule>` syntax/special function
was what the TC39 committee agreed to for lazy/dynamic imports after much
bikeshedding. It's a Stage 3 ES proposal [1], which means it is likely in the
next ES spec version, and is already supported in some browsers and many tools
(such as webpack).

[1] [https://github.com/tc39/proposal-dynamic-
import](https://github.com/tc39/proposal-dynamic-import)

------
stevebmark
"type hell" seems to be far worse than "dependency hell," where the open
source type definitions you use can have minor inconsistencies with each
other, many of which are out of your control, causing lots of useless type
errors in any project with even medium complexity. This forces engineers to
ignore type errors, defeating the purpose of Typescript entirely.

Has anyone had a truly pleasant experience with Typescript in a medium to
large project?

~~~
eitland
> "type hell" seems to be far worse than "dependency hell," where the open
> source type definitions you use can have minor inconsistencies with each
> other, many of which are out of your control, causing lots of useless type
> errors in any project with even medium complexity.

Tried twice to wrap my head around what you are even talking about.

TypeScript is totally wonderful. It's also optionally typed.

I use it on a non trivial project with multiple teams.

Was introduced to it last year and it's fantastic compared to plain js.

~~~
mediumdeviation
Example: [https://imgur.com/oR3Nk8q](https://imgur.com/oR3Nk8q)

This was generated by one line of code, simply applying the hoist-non-react-
statics library as recommended by the official React docs
[https://reactjs.org/docs/higher-order-
components.html#static...](https://reactjs.org/docs/higher-order-
components.html#static-methods-must-be-copied-over)

JavaScript in many cases can be too dynamic to be properly typed. I'd rather
have it than not - it has saved my ass a good number of times - but let's not
pretend TS/Flow is _totally_ wonderful.

~~~
WorldMaker
I've only recently started into React, but my impression is because many React
teams use Flow or nothing at all, the Typescript types definitely lag behind
releases.

At some point I hope to sit down and start filing bugs/sending PRs to fix many
of the React Typescript types I find, but in the meantime there are several
React modules I've replaced the with just `declare module 'react-thing'` to
jus any-type it and move on.

------
arenaninja
Gotta love the sanity that TypeScript brings to web development, if not for
TypeScript I'd rather write PHP over JS

For good measure I recently wrote a blog post on writing your first
TypeScript+React application: [https://charmeleon.github.io/post/react-
typescript-tic-tac-t...](https://charmeleon.github.io/post/react-typescript-
tic-tac-toe/)

~~~
shabbyrobe
PHP cops a lot of heat - some deserved, but mostly not - largely based on
limitations of previous versions, cosmetic issues like the crummy naming and
argument ordering in the stdlib, and good old fashioned out-grouping, but it
has had optional graduated type safety for many, many years. Moving from PHP
to Node felt like a major step backwards in the sheer number of unit tests and
argument sanitisation junk I used to not need to write.

I'm so grateful for TypeScript, it's the hero JavaScript desperately needed.

------
jhoh
I've been using TypeScript for around one year now in small to mid sized
projects but I feel like I'm not using a lot of the language's features and
best practices. Does someone know any good advanced courses (free or paid)?

~~~
juol
Yeah I'm in the same boat. I've been spending a bit of time looking into some
of the big and popular Typescript projects. But something's not sinking in and
I could use a intermediate/advanced guide.

------
huy-nguyen
I hope they will some day implement variadic types:
[https://github.com/Microsoft/TypeScript/issues/5453](https://github.com/Microsoft/TypeScript/issues/5453).
Also, the plan for a 3.0 release looks a bit underwhelming:
[https://github.com/Microsoft/TypeScript/wiki/Roadmap#30-july...](https://github.com/Microsoft/TypeScript/wiki/Roadmap#30-july-2018).
Why not call that 2.10?

~~~
Scarbutt
_Also, the plan for a 3.0 release looks a bit underwhelming_

They have added a ton of language features and keep adding more with each
release, lets hope it doesn't get bloated as scala.

~~~
amzans
IMO Scala has a lot of very well thought out features that complement each
other, and this is only going to get better with the move towards Dotty.

For me it feels not as bloated as other languages which added features without
thinking about how they fit to the existing ones. But I work a lot on Scala,
so I'm probably biased since I know the language better than i.e. Typescript
:)

~~~
Cthulhu_
The problem / challenge is that there is too many choices, too many ways to
tackle a certain problem, and every library you find will have a different
method. Plus each one introduces some university / Phd level mechanic that
most developers (e.g. me) don't understand.

~~~
amzans
I understand the problem with that, and agree with you.

While it can be very empowering to have a "sandbox" language, when it comes to
shipping features and working in a team setting, it can require a lot of
discipline to keep the codebase approachable for others. Languages like Go or
even Python seem to help a lot in there by having strong conventions and an
"obvious" way to do things.

------
pininja
I’m a fan of the “Generic type arguments in JSX elements” - ran into a case
where I needed it a few months ago. They’ve always had a workaround, but this
is more concise.

~~~
btown
So much better than the workaround here:
[https://github.com/Microsoft/TypeScript/issues/3960#issuecom...](https://github.com/Microsoft/TypeScript/issues/3960#issuecomment-301381447)

    
    
        type TemplateTypedSelect = new () => Select<Template>;
        const TemplateTypedSelect = Select as TemplateTypedSelect;
        return <TemplateTypedSelect {...props} />;
    

Our codebase was sprinkled with these, which was both silly and error-prone.
This will be a huge quality-of-life improvement, and encourage people to
create type-safe React components that ensure a match between their inputs and
callbacks, rather than just having them put a union of all the types they can
handle in both.

------
knocte
The only things that put me off about typescript are:

a) The lack of a proper 'is' keyword. The current behaviour around this is
mental.

b) The unneeded complexity that the recent releases have brought to the typing
system.

~~~
Too
Do you mean instanceof? The javascript operator still works as before? Though
typescript is designed around interfaces/ducktyping, which is almost the
opposite of instanceof; as long as a type satisfies the interface constraints
it walks like a duck and should be sufficient.

~~~
mathw
Maybe they should have had a "quackslike" operator :)

~~~
sime2009
TypeScript does support writing "quacksLike" functions. The feature is "type
guards" and it lets you write a boolean function to test the type of an
argument, and TS's flow control code understands it at compile time.

    
    
        const something: Animal = ...
    
        if (isDuck(something)) {
            someThing.quack();  // TS can OK this
        }

------
Too
Maybe it's too early in the morning but i had a really hard time understanding
the changes around keyof and mapped types and what it's good for. It felt very
mathematically academic. Does anyone have real world examples where it's
useful?

~~~
edvald
I'm a pretty heavy TS user and I was pondering the same thing. I've not been
able to find a motive for allowing numbers as interface keys, but Symbols
actually do make sense since, turns out (I'm always learning something new),
you can use them as object keys in ES6:
[https://www.keithcirkel.co.uk/metaprogramming-in-
es6-symbols...](https://www.keithcirkel.co.uk/metaprogramming-in-es6-symbols/)

That post outlines a few use cases which are admittedly outside of everyday
JS/TS usage but I can see them as quite powerful when, for example, building
frameworks and libraries that expose an API. I'd offer real-world examples of
my own but I'm still working it out for myself .)

~~~
WorldMaker
JS allows numbers as object keys (though it's one of those weird behavioral
swamps where arrays act differently from objects, and sometimes they are
coerced to strings [objects] and sometimes not [arrays], depending), so this
mostly seems that its just about getting better at defining the existing JS
behaviors of things, modulo the "quirks" of course.

A lot of this matters in "metaprogramming" like Readonly<T> and Partial<T>
which use all of the existing keys in a type to produce a "new" result (none
of the key can be set, and all of the keys are optional, respectively), and
making sure it doesn't miss intentional keys like symbols and numbers.

------
hellofunk
How does typescript compare to ReasonML?

------
CrypticOne274
Great. Got to love breaking changes.

~~~
manigandham
The only "breaking" change is a stricter type check for _keyof_ , and strict
type checking is the entire reason for existence of TypeScript.

~~~
latchkey
...which broke projects that use material-ui.com [1].

[1] [https://github.com/mui-org/material-
ui/issues/11656](https://github.com/mui-org/material-ui/issues/11656)

~~~
manigandham
Yes, breaking changes potential break things, the point being in this case
Typescript is getting better at doing its job and the change is rather minor.

Also it clearly states: _" use --keyofStringsOnly compiler option to disable
the new behavior"_

~~~
latchkey
Apologies, my comment was not a complaint. I'm all for type safety and a huge
fan of typescript!

