5 ms·

How well does Typescript play with existing node packages? Last I checked you need to do some work extra work (typings?) to get it working. That's the biggest r

How well does Typescript play with existing node packages? Last I checked you need to do some work extra work (typings?) to get it working. That's the biggest reason I've not yet switched over to typescript.

nicoburns 8y ago
It has support for external type definitions, which can be installed from NPM like any other package. These are only necessary for packages which don't support typescript themselves. But it can definitely be an issue for smaller, less well supported packages where you can be left with a choice of writing type definitions yourself or turning off type safety for that library (using the `any` type).
- stupidcar 8y ago
  I don't see that as much of an issue though. You wouldn't get any type-checking if you weren't using TypeScript, so it's still a net gain even if a few packages are `any`.
kageneko 8y ago
A lot of packages have types built into them. Others have types available in "@types/<package>". For everything else, I create a "types.d.ts" file that just has a bunch of stuff like: declare module 'twilio'; declare module 'bitly'; declare module 'cloudinary'; declare module 'tmp-promise'; declare module 'dialogflow'; declare module 'fuel-rest'; And then those modules get set to the "any" type.
udp 8y ago
You can use any regular JS library from typescript. You just won't get type checking in calls to it.
minimidge 8y ago
That's true, but typings exist for most of the common packages: npm i express @types/express It usually "just works", but it really depends on how obscure the packages you're using are. 4,720 type definition files at the moment: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...
_hardwaregeek 8y ago
It's not the best. I had to trawl through a bunch of documentation and filter out old info (modules became namespaces? I think?), and try different formats for the typings file. Tbh there should be a FAQ that is just: Help, the compiler is complaining about a package, how do I fix it? Also, why do I need to clone the DefinitelyTyped repo and make a PR to add a typing file? Why can't I just make an NPM package? These are all nitpicks in light of the amazing achievement that is typechecking JavaScript. But I wouldn't mind a little more ergonomics for package typing.
- WorldMaker 8y ago
  It's hopefully getting easier. Many libraries increasingly just pack their own definitions, which really is the best case. `npm install package` and done. Writing a temporary definition file to just make something work is as easy as a one-liner in most cases now (make a .d.ts file somewhere in your project and add: `declare module 'module-name'` and/or `declare module 'module-name/*'`, depending on how the module is supposed to be used). > Also, why do I need to clone the DefinitelyTyped repo and make a PR to add a typing file? Why can't I just make an NPM package? It is possible. DefinitelyTyped is a publishing infrastructure bottleneck for sure. But it's a useful infrastructure bottleneck in doing somewhat minimal gatekeeping of the `@types` namespace on NPM and keeping it from filling with garbage. (I was a somewhat vocal critic of it before NPM @types, but I've mellowed again on it, partly because it is shrinking slowly in some areas as more NPM libraries adopt types directly. Some of my favorite contributions are PRs to remove types in DT because a library added their own directly to their NPM packages.) Though a baked-in default in Typescript, @types is only semi-magic. The configuration knob is called typeRoots [1]. You can't configure a recursive search path like `@types` with it, but you can use it for experimenting with non-DefinitelyTyped types packages. (DT itself uses typeRoots internally for all of its testing.) [1] https://www.typescriptlang.org/docs/handbook/tsconfig-json.html https://www.typescriptlang.org/docs/handbook/tsconfig-json.h...
sbjs 8y ago
Probably 90% of third party libraries I ever used in my TypeScript projects have TypeScript interfaces built into them, so you just install the package like normal `npm i -P somelib`, and TypeScript automatically knows its types. Maybe 9% of them don't, and you have to add types like `npm i -D @types/somelib`. And the other 1% you can add manually yourself by adding them into `global.d.ts` in your project and only creating types for the functions you actually use. I only ever had to do this once, and it took about an hour total. It would have been more like 5 minutes if I had known that you can use the `typeof` operator in TS to specify that a given field is a constructor of another type.
whatever_dude 8y ago
If a package doesn't have a typing you just do `declare module "whatever";` in a global.d.ts file and you're all set, you can use it as you would in JavaScript (it's typed to any). Hardly a problem at all.

nicoburns 8y ago

It has support for external type definitions, which can be installed from NPM like any other package. These are only necessary for packages which don't support typescript themselves. But it can definitely be an issue for smaller, less well supported packages where you can be left with a choice of writing type definitions yourself or turning off type safety for that library (using the `any` type).

stupidcar 8y ago
I don't see that as much of an issue though. You wouldn't get any type-checking if you weren't using TypeScript, so it's still a net gain even if a few packages are `any`.

kageneko 8y ago

A lot of packages have types built into them. Others have types available in "@types/<package>". For everything else, I create a "types.d.ts" file that just has a bunch of stuff like: declare module 'twilio'; declare module 'bitly'; declare module 'cloudinary'; declare module 'tmp-promise'; declare module 'dialogflow'; declare module 'fuel-rest'; And then those modules get set to the "any" type.

udp 8y ago

You can use any regular JS library from typescript. You just won't get type checking in calls to it.

minimidge 8y ago

That's true, but typings exist for most of the common packages: npm i express @types/express It usually "just works", but it really depends on how obscure the packages you're using are. 4,720 type definition files at the moment: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast...

_hardwaregeek 8y ago

It's not the best. I had to trawl through a bunch of documentation and filter out old info (modules became namespaces? I think?), and try different formats for the typings file. Tbh there should be a FAQ that is just: Help, the compiler is complaining about a package, how do I fix it? Also, why do I need to clone the DefinitelyTyped repo and make a PR to add a typing file? Why can't I just make an NPM package? These are all nitpicks in light of the amazing achievement that is typechecking JavaScript. But I wouldn't mind a little more ergonomics for package typing.

WorldMaker 8y ago
It's hopefully getting easier. Many libraries increasingly just pack their own definitions, which really is the best case. `npm install package` and done. Writing a temporary definition file to just make something work is as easy as a one-liner in most cases now (make a .d.ts file somewhere in your project and add: `declare module 'module-name'` and/or `declare module 'module-name/*'`, depending on how the module is supposed to be used). > Also, why do I need to clone the DefinitelyTyped repo and make a PR to add a typing file? Why can't I just make an NPM package? It is possible. DefinitelyTyped is a publishing infrastructure bottleneck for sure. But it's a useful infrastructure bottleneck in doing somewhat minimal gatekeeping of the `@types` namespace on NPM and keeping it from filling with garbage. (I was a somewhat vocal critic of it before NPM @types, but I've mellowed again on it, partly because it is shrinking slowly in some areas as more NPM libraries adopt types directly. Some of my favorite contributions are PRs to remove types in DT because a library added their own directly to their NPM packages.) Though a baked-in default in Typescript, @types is only semi-magic. The configuration knob is called typeRoots [1]. You can't configure a recursive search path like `@types` with it, but you can use it for experimenting with non-DefinitelyTyped types packages. (DT itself uses typeRoots internally for all of its testing.) [1] https://www.typescriptlang.org/docs/handbook/tsconfig-json.html https://www.typescriptlang.org/docs/handbook/tsconfig-json.h...

sbjs 8y ago

Probably 90% of third party libraries I ever used in my TypeScript projects have TypeScript interfaces built into them, so you just install the package like normal `npm i -P somelib`, and TypeScript automatically knows its types. Maybe 9% of them don't, and you have to add types like `npm i -D @types/somelib`. And the other 1% you can add manually yourself by adding them into `global.d.ts` in your project and only creating types for the functions you actually use. I only ever had to do this once, and it took about an hour total. It would have been more like 5 minutes if I had known that you can use the `typeof` operator in TS to specify that a given field is a constructor of another type.

whatever_dude 8y ago

If a package doesn't have a typing you just do `declare module "whatever";` in a global.d.ts file and you're all set, you can use it as you would in JavaScript (it's typed to any). Hardly a problem at all.