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`?
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.
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.
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)
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.
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).
I would fix this by undoing the change to lib.d.ts, which is a nonstarter, but which I see as a mistake. I do actually think your point is valid: fixing is better than complaining. But I also think language devs should fix iterator bugs in under two years.
Exactly. For my taste they already added too many language features, which each time raises the mental bar to use it when you didnt use it for a couple of month.
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 :)
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.
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.
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"
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.
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.
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.
"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?
> "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.
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.
Error messages like that are pretty bad, yeah. I'm still a fan of TS myself though, the challenge is that there's some less-well-designed JS libraries that are, like you said, too dynamic to be properly typed.
It's bringing OOP back from having almost been forgotten, and with it, a reminder of proper library design and data types.
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.
Looks like a jetbrains IDE, I'm a massive fan of intellij and it's my goto programming environment but it's type error messages with typescript are terrible compared to vscode (enough that if I can't understand what the hell it's saying I'll boot vscode).
It's about the one thing I can really ding intellij for at the moment.
Lucidchart and Lucidpress are large projects that are almost entirely TypeScript on the frontend. The team really likes it. We use TypeScript and Angular that is compiled using Tsickle and the Google Closure Compiler.
It's not perfect, but we have found the types to be very nice when working on a large code base with lots of people. Dev development cycle remains quite fast.
My company's app is around 40k lines of TypeScript and our experience has been GREAT. There have been occasional hiccups when upgrading dependencies, but they're few and far between, and the safety and clarity the types give is more than worth it.
Resolving conflicts between third party typings from DefinitelyTyped has cost me a lot of time over the last couple of years. The typings we use are maturing a bit, but at one point someone merged a completely unnecessary refactoring of the React types that caused compatibility problems for months until all other dependencies were upgraded.
Using yarn.lock means it never breaks unless we specifically choose to upgrade though, so it's still worth the increased productivity and safeness from TypeScript, which is awesome as a language especially combined with VS Code.
DT has a problem in that they try to track the semver breaks of upstream in their npm packages, but don't have a good way to handle semver breaks caused by type refactors/cleanups/etc.
DT packages almost need _two_ version numbers that npm checks for semver breaks, but how to make that work is an open question and an interesting edge case in package management.
(I got some hate for one of my refactors, that I needed to get my own code to type correctly, that touched quite a few DT packages in the "middle" of an upstream major version, so I know this pain quite directly from both sides.)
Yes. We develop a large Angular app. When the framework itself is written in TypeScript, and by extension, most of the ecosystem code ends up being TypeScript as well, and we have not really faced any major typing issues.
On the other hand, when writing server code targeting Node, with lots of dependencies on micro-libs, I've definitely had the experience of struggling with outdated or incorrect type definitions.
However, nowadays TypeScript has much better interoperability with untyped JS code. You can generally import an untyped JS module with the minimum of ceremony and have it Just Work (the type will be "any", so you don't get intellisense).
I find the best approach is to import types for the big libs you are using, like Express, and leave the micro-libs untyped. That way you get the benefit of types on your own code and your interactions with the framework, but can still leverage other code when you need to without giving yourself a headache.
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)?
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.
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.
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
}
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?
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...
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 .)
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.
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`?
reply