3 ms·

typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/

typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j... I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works! Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.

mirekrusin 6y ago
You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?
- emptysea 6y ago
  Generics are supported via `@template` https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#template https://www.typescriptlang.org/docs/handbook/type-checking-j... types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}` There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice since our devs are already using typescript in other places. Can even using things like https://github.com/typescript-eslint/typescript-eslint https://github.com/typescript-eslint/typescript-eslint Flow is both more advanced and faster than Typescript, but the community isn't as large, so Typescript continues to gain marketshare
  - mirekrusin 6y ago
    If it supports many constructs, why they don't switch to using it in deno?
    - vimslayer 6y ago
      I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that. I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS through Babel and it has been a breeze for much larger projects than that. Babel just strips away the TS types and we do type checks via editor integration and a separate CI step. Can't recommend this setup enough.
      - mirekrusin 6y ago
        It's not only compile times, it's also runtime code it generates and issues it creates in some cases, article mentions it.

mirekrusin 6y ago

You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?

emptysea 6y ago
Generics are supported via `@template` https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#template https://www.typescriptlang.org/docs/handbook/type-checking-j... types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}` There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice since our devs are already using typescript in other places. Can even using things like https://github.com/typescript-eslint/typescript-eslint https://github.com/typescript-eslint/typescript-eslint Flow is both more advanced and faster than Typescript, but the community isn't as large, so Typescript continues to gain marketshare
- mirekrusin 6y ago
  If it supports many constructs, why they don't switch to using it in deno?
  - vimslayer 6y ago
    I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that. I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS through Babel and it has been a breeze for much larger projects than that. Babel just strips away the TS types and we do type checks via editor integration and a separate CI step. Can't recommend this setup enough.
    - mirekrusin 6y ago
      It's not only compile times, it's also runtime code it generates and issues it creates in some cases, article mentions it.