191–200 of 469 posts
Are tests useful? Because this is what TypeScript gives you: it helps you avoid regressions. If I change a signature, tests fail. If I pass junk data, tests fail. It's like invisible live tests and people forget this. As in the other recent discussion, yeah, you can live without tests and you can live in JS-land. Whether it's worth it it depends on you. TS and traditional testing lets me ship updates without even ope…
Hi there! I work on the TypeScript team and I respect your feedback. Of course I do think TypeScript is worth it, and I'll try to address some of the points you've raised with my thoughts. i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing bu…
Earlier quoted context omitted.
> many useful and popular libraries do not include full documentation of their types > but many authors choose to show their examples in JS, in order not to be too opinionated This is certainly true sometimes, but I don't see why it's a reason against using TypeScript? If you're calling a TypeScript API, the way you use it should look basically the same as the way you'd use it in JavaScript. You usually don't have to…
I am thinking of the case where you are passing an object or class to an API that needs to be shaped a certain way. In this case you need to know which type to import/use to pass it through. For many simple libraries it's not too much of an issue, but for more complex things like Apollo (which also doesn't include much TS in their docs) it's a lot of hit and miss until you get it right.
I will also say- GraphQL almost by nature is gonna be a really hairy thing to statically type, especially on the server side. We've got an Apollo server at my company and thus far we've pretty much just punted on trying to type that part of things. Which is also more okay than might be for other things, because GQL does its own runtime validation anyway
Hi there! I work on the TypeScript team and I respect your feedback. Of course I do think TypeScript is worth it, and I'll try to address some of the points you've raised with my thoughts. i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing bu…
Thanks for responding, and thanks for your work for the community! I sometimes place myself in the shoes of devs building TypeScript, especially when I am a little frustrated, and most of the time I realize that a lot of these issues are incredibly hard to solve. > i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference migh…
Yes. There are even issue templates to guide you through writing an issue that the team will be able to address effectively.
I would simply refuse to work on a JavaScript project at this point.
If you're talking about general backend languages, then there are a lot of options. Since you're talking about large scale applications, that likely means you can use something like java or kotlin.
One of the biggest mistakes that I see devs making is caring too much about making TypeScript happy when they know it doesn't really matter. There are a lot of cases where it's totally reasonable/rational and honestly fairly safe to just throw in a well-scoped "any" cast, a `// @ts-expect-error` comment, etc. If you know what you're trying to do, and TS isn't understanding, sometimes it's just a lot more expedient to…
This feels like telling Haskell developers that they should use unsafePerformIO and unsafeCoerce more.
#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all. #2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of do…
The net result is that greenfield TS projects often end up simpler and faster but that’s not very useful for someone buried in an old JS project that enthusiastically abuses the dynamicness allowed.