2 ms·

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

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...

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...