Live data from Hacker News

TypeScript 3.5

devblogs.microsoft.com

21–30 of 88 posts

Re: TypeScript 3.5

#21
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

For the comment about not being able to use JS libs that don’t have typedefs, this is why I wish Facebook’s Flow was more popular. You can use as much or as little of typing as you want and don’t need to to write typedefs for every JavaScript lib you wish to use. It also had static code analysis that could infer types.

Re: TypeScript 3.5

#22

Earlier quoted context omitted.

I second that, to a degree. I write mostly TypeScript and Rust these days and it still behaves unexpectedly sometimes. Example: for a service we wanted to port Rusts’ Result. https://gist.github.com/KenanSulayman/34a40daa3ebbd1e1bdf7c7... Notice the ‘as any’ and ‘_T!: T;’ et al. hacks to make it work. Other than that it’s completely a one to one port from the Rust core implementation.

Because you're trying to manually optimize code, which is kindof like saying 'I konw what I'm doing so TypeScript please shut up'. Take for example the `map_err` function of the `Ok` class. The function returns a different `Result`, but you're using the `… as any` trick to shut up the compiler. The correct implementation would be: map_err (fn: (arg: E) => U): Result { return new Ok (this.value) } I see why you're not…

To be clear, the option type in rust does not heap allocate at all; no need for the compiler to optimize things away.

Re: TypeScript 3.5

#23
post #5

Typescript 3.5: fixing the problems we introduced and providing workarounds for new features in a broken type system.

I can't downvote you but I want to point out that the only thing you accomplish with such a comment is coming off as ignorant and bitter.

I have no idea why on Earth you think the type system is broken. Objectively, it simply isn't, obviously, but I'd love to see you trip over your own feet trying to argue that it is.

Moreover, it's honestly remarkable how they've managed to retrofit such an amazing type system on top of an already existing language and have it feel so natural. It's truly an impressive feat of engineering.

Re: TypeScript 3.5

#24
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

[deleted]

Re: TypeScript 3.5

#25

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

Very specifically, 3.4 had a few perf regressions for some type signatures [1]. More generally, TS can be a bit slow (~seconds) especially for large webapp development if you need hot-reloading and such. There are tricks to emit without checking and doing async checking during the dev process which speeds things up quite a bit.

[1] https://github.com/Microsoft/TypeScript/issues/30663

Re: TypeScript 3.5

#26
post #25

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

Very specifically, 3.4 had a few perf regressions for some type signatures [1]. More generally, TS can be a bit slow (~seconds) especially for large webapp development if you need hot-reloading and such. There are tricks to emit without checking and doing async checking during the dev process which speeds things up quite a bit. [1] https://github.com/Microsoft/TypeScript/issues/30663

I'm using 3.5.1, the issue is I don't have very many files and it's in a Node environment where it transpiles the file to the output directory with no bundling or hot reloading included.

What are some of these tricks to skip checking or do async checking? I did a quick search and came up with a GitHub issue [0] for adding the option to skip checking, but didn't see anything myself.

[0] https://github.com/Microsoft/TypeScript/issues/29651

Re: TypeScript 3.5

#27

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

Typically, TypeScript type-checks `lib.d.ts` every single compilation which can add at least half a second of build time. It will also do a full check of `.d.ts` files in your dependencies, which can also be pretty heavy.

We're considering ways we can avoid a full type check: https://github.com/microsoft/TypeScript/issues/31417

In the meantime, you can try out turning on the `skipLibCheck` compiler option to see if that helps at all, but be warned that it might not catch conflicts across multiple files.

Re: TypeScript 3.5

#28
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

> 'x' as 'x'

As others point out, 3.4 added `as const` which is more powerful and more generic.

> Add to that, in many cases being unable to import a JS library in that doesn't include typedefs, and I fail to see how TS can be considered a superset of JS. It's certainly sold that way, but it's clearly not totally true. TS+React requires --noImplicitAny, which cannot be worked around (it's labeled as being required due to a platform limitation).

No implicit any just restricts the type system from falling back to `any`, it doesn't stop you from explicitly using `any`. Most places where you get a noImplicitAny error you can add an `as any` or a `: any` assertion nearby. Explicit `any` is still often useful, even if only as a TODO marker for that day you can search for `any` in the codebase and try to remove it.

There's also `as unknown` or `: unknown` type assertions as another option for `any` in some case (`unknown` is stricter than `any` and implies you are going to be testing the value for runtime type information).

Use an explicit `any` applies to modules too. That problem with importing a JS library but getting a noImplicitAny error can be solved with an explicit `any`. That's where one particularly useful real world case of `declare` comes in. Add a file called something like `modules.d.ts` (the `.d.ts` is a convention that it won't have actual TS code, just declarations) and then to add explicit `any` for any module you want to import is as simple as:

    declare module "modulename";
`declare` is how you write type definitions for JS code. The simplest declaration is that a module exists and could be anything.

> I also find Microsoft's documentation of TypeScript to be very poor

There's a better documentation site being built with better search and with a lot more interactive examples. I don't know when it might be expected to be released, but BUILD talks seemed to indicate that Microsoft is aware that Typescript's documentation hasn't kept up with its release cadence and needs love.

Re: TypeScript 3.5

#29

Earlier quoted context omitted.

This doesn't need magic powers. All you have to do is treat literal values inside type descriptions differently.

Inside of type descriptions, literal values are always treated as literals. The problem only appears when you declare a variable _without_ an explicit type like `const foo = {k: 'x'}`, which the compiler then infers to be of type `foo: {k: string}` and not `foo: {k: 'x'}`. Both of these are valid inferences, and it's impossible to know which one the user wants in the general case, which is why you have to explicitly…

So the example of `false | 'x' | 'y' | undefined` turning into string is invalid?

I feel like I'm missing something.

Re: TypeScript 3.5

#30
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

For the comment about not being able to use JS libs that don’t have typedefs, this is why I wish Facebook’s Flow was more popular. You can use as much or as little of typing as you want and don’t need to to write typedefs for every JavaScript lib you wish to use. It also had static code analysis that could infer types.

TS can infer types in some cases (when the --allowJs option is on and the JS files are a part of the project, for instance), and it is on the roadmap to continue to make that stronger.

TS also doesn't need typedefs for every JS lib. It now defaults to assuming any module import is type `any` if it doesn't have typedefs and can't infer from the JS files for whatever reason.

In the case of the comment above the complication is using JS libs and also the compiler flag --noImplicitAny which causes an error on importing a module that defaults to type `any`. Making that an explicit `any` (with a `declare module "modulename";` in a .d.ts file) is all that is needed.

Post reply on HN