shutterstock
Provide type definitions for common-errors
Can you provide type defintions in your project or trigger a separate task as described here: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html Usually the owner of a npm module add the definition in the repo: https://github.com/DefinitelyTyped/DefinitelyTyped and the build process automatically push a new type module to npm.
Is this really a desired feature? I haven't ever wanted to use TypeScript personally since I love dynamically typed languages, and I have an affinity to stick with native JS. A while ago, someone submitted a PR that I rejected because I didn't want to maintain it for a small user-base. https://github.com/shutterstock/node-common-errors/pull/24
Can you confirm this PR is what you want, and can you also show me that this adds value to people?
Hi David,
yes definition files for the package would be great. I am not sure about the content of the PR but the value of a type definition of your package. More and more developer in my team if more packages exists with the same idea select a package with type definition instead of a other.
It would support developers with typesafe development during transpiling but also in during development time because IDEs can check if the usage of the package is correct. And typesafe development become more and more popular in production development. Also plain nodeJS developers would get support from IDEs. As Javascript/Node developer using for example VSCode the IDE you also give you help for attributes and functions if the type definition is available.
added value to people:
- support during development (type check)
- support during development (in place documentation and help)
- ensure production code use correct function syntax (transpiling check)
The type definition document is a formalized version of your text documentation.
I'm still not sure if it's worth adding Typescript to this project. If enough people subscribe to this issue or comment in it, I'll maintain some typescript definitions.
I'll leave the issue open as a result.
I just had a need for types for common-errors, resorted to defining our own override types for the API surface we needed right now (some Error types and helper/generateClass stuff). Followed these instructions for now but would be nice to have proper full typings from @types.
Also needed @types for common-errors, searched the main repo, found none, generated my own.
Here's my number one argument in favour of adding TS definitions to libraries: it adds literally no friction for users that don't use it, and significantly reduces friction for users that do. I can't count how many times I've installed a new library and been positively delighted when my IDE started to help me learn this new library automagically.
Producing them is trivial; even if you're not into the game of writing quality TS defs (which there is a lot to be said for), you can generate them – just like I did – as part of your build process using dts-gen without having to think about it. Your users won't get all the nice pop-up documentation that goes with well-written defs, but they'll at least be able to see what properties your objects have as they're typing.
This isn't just about static/dynamic typing – there's a lot more to gain here.
Yes TypeScript definitions are definitely useful. @dfenster You should really add them
