TypeScript 3.5
devblogs.microsoft.com
devblogs.microsoft.com
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 requires me to write the following value to avoid a type error:
'x' as 'x'
This is not the only time I've run into this kind of problem -- I run into this problem regularly -- this is just the simplest version of it that I've experienced. I just cannot take a type system seriously when workarounds like that are needed.
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).
I also find Microsoft's documentation of TypeScript to be very poor (and has no search feature -- I'm sure they have some convenient excuse for that). I tend to learn how things work from random Github comments or source code after reading the documentation over and over. What is `declare` used for in practice? They don't really say, they just say it's for declaring things, and give highly specific examples.
Maybe I'm the odd one here and maybe I'm missing some piece of information that a lot of TypeScript developers have, but I've yet to find it and given all the choice I have these days, there are numerous languages I would choose well before TypeScript.
Are you familiar with type theory and how easy it is for a type system to require too much work to be useful? Especially with conditional types. TypeScript has been doing a phenomenal job.
For this particular use case, since version 3.4 you can write `'x' as const` which will work no matter how large your type is.
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.
map_err<U>(fn: (arg: E) => U): Result<T, U> {
return new Ok<T, U>(this.value)
}
pub fn map_err<F, O: FnOnce(E) -> F>(self, op: O) -> Result<T,F> {
match self {
Ok(t) => Ok(t),
Err(e) => Err(op(e))
}
}
As it is, Ok only depends on T and Err only depends on E, so why do you have them depend on both?
One problem is that TS does not want to merge unionized function signatures like this:
map: (<U>(fn: (arg: "yep") => U) => Ok<U>) | (<U>(fn: (arg: any) => U) => Result<U, "nope">)
I couldn't figure out .map_or_else, but .map().or_else() works.
Admittedly, with this way you can get an output of Ok<a> | Ok<b> from some functions, but I don't know where that would be a problem (still fully type checked, you would just get the expected error further outside.
Here's a updated gist: https://gist.github.com/phiresky/621f8d8ed6eb00c9a0ddb47217e...
Make sure you have "allowJs": true in your tsconfig.json. Otherwise, you'll have to create a minimal file with `declare module "xyz";`
> I fail to see how TS can be considered a superset of JS
You have to interpret all TS "errors" as warnings for that to be true (which they mostly are considering tsc still emits code regardless of non-syntax-error errors)
> I just cannot take a type system seriously when workarounds like that are needed.
Your problem really just seems to be that the type inference does not have magical powers. There is no other programming language that has union types as powerful as TypeScript (as in discriminating by whatever you want), but yeah when you do `return {x: 1, y: 2}` the compiler doesn't always know whether you mean to return an object where the type of x is `1` or where it is `number`. In some cases it could be better still, but doing this in general is just not possible.
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 say `const foo = {k: 'x' as const}`.
I feel like I'm missing something.
function test(p: {k: false | 'x' | 'y' | undefined}) {
// do stuff
}
const p = {k: 'x'} // inferred type: {k: string}
//...
test(p); // type error : Type 'string' is not assignable to type 'false | "x" | "y" | undefined'
If you add `as const` or an explicit type to p it is fine.
(I think this is what the GGP was referring to)
How about Swift and OCaml? ReasonML comes to mind too. Haven't tried actively comparing any of them though.
type union = Bool of bool | Char of char | Nothing
let (x, y, z) = (Nothing, Bool true, Char 'x') let a = random() ? 'a' : 1
string | numberI merely know from experience that they have a pretty good type system, but not much more. So I asked :-)
Answers have been enlightening
Ada's record [0] type stands out. From what I can see, TS' unions are not nearly as powerful.
[0] https://en.m.wikibooks.org/wiki/Ada_Programming/Types/record
I suggest looking into Idris and other languages with dependent types. Nothing against typescript, but it’s not even close.
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.
(I've used Flow for a long time. I'm starting to transition a large codebase from Flow to Typescript, and I'd highly recommend anyone to just start with Typescript rather than Flow. Flow's type inference isn't all that useful, and causes Flow to be magnitudes slower than Typescript. In a large codebase, it can take Flow tens of seconds to minutes to react to a code change and show you errors or auto-completions in your code after typing in an editor, compared to practically instantaneous updates with Typescript.)
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";
> 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.
Hmm .. as far as I'm aware, they haven't added this yet: https://github.com/microsoft/TypeScript/issues/1213
Note that higher-kinded types (though I'd rather call it "higher-kinded polymorphism" or something—type-level functions are not really types) would allow code similar to this:
function foo<F, A>(f: (v: A) => F<A>, v: A): F<A> {
return f(v);
}no they did not, if they did it would've been a major news.
- Omit helper type
- Smart Select (allows editor to expand/shrink selection based on syntactic construct)
- Extract to type alias (smart refactor of function parameters to their own type)
- Performance improvements
Did they ever get a solution in place for partial function application (e.g. - as for Ramda.js)?
When this gets to the point where the only place I have to define explicit types is for JSON data read from the network, I’ll consider using it.
I know I’m in the minority, but I’d rather NOT have any type checking than have to read through Java-esque drivel (at least most modern languages put the types after the identifier like Pascal does, rather than before like C). In practice, I don’t spend much time chasing type errors, but do spend too much time reading through MEGO inducing verbiage which I would just as soon not.
I looked into combining tsc-watch and jest, but jest does not currently support a public API. tsc-watch already emits an event on success which should be able to trigger (an already running!) test runner to incrementally test again.
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.
More generally though you have two loops one that does transpileOnly and one that doesn't. The latter is your type check process.
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.
I tend to notice all compilers as feeling "too slow". I think the cause is that we all have wayyyy too much code. Not that we write, but when we use a library, that uses 10 libraries, that each use 10 libraries. Now you have a million lines of code, and all you wanted to do was print hello world. The compiler doesn't know until it's read all of that that you aren't using any of it. The solution is to depend on libraries more carefully.
As the go team says, a little copying is better than a little dependency. This is a motto that the npm community has NOT taken to heart. The cost is slow build times. (To be fair, the go community has not taken this to heart either.)
I don't really notice it, though, because I've got `tsc --watch` running in a terminal continuously as I edit code.
When tsc sees edits, recompilation competes in tens of ms. It's really quick.
1) Operator overloading
2) Runtime type checking of JSON payloads (on dev env at least)
Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2
And the most common error that it should help catch during development is that you get a JSON and you cast it but it means nothing cause on runtime the JSON can be something completely different and nothing breaks until is somewhere else hard to debug, I get that Microsoft don't want to add runtime overhead but it should be possible at least on development mode.
Please, please, please, no.
On the other hand, there's only one language that I'm aware of - TypeScript - prioritizing these things, which is a major selling point of it to me. I don't want yet another leaky abstraction, or yet another runtime heavy enough for those abstractions to not leak.
I just want enough types for my intellisense to work right, and for my sorry ass - spoiled by years of nothing but static typing systems - to be able to code without drowning in a veritable sea of uncaught type errors to debug, when I poke frontend stuff.
You can even define the type via io-ts and then make a TypeScript interface out of it!
Given this, and the other libraries that do something similar, I am not sure why Microsoft needs to add it to the language.
If you want to write clever DSLs and/or name methods in ways that save keystrokes like in scala, NO, please.
2) There are libraries such as runtypes and io-ts that integrate well with the static type system
[1] https://www.typescriptlang.org/docs/handbook/advanced-types....
We've been using Mobx State Tree for this, which also gives us frontend models and automatically generates interfaces. Obviously only works for you if you're using Mobx, but we love it.