1

I have been using typescript for a little while in node.js projects. I understand that for many npm packages there is separate @types package for typescript type definitions.

My question is: how can I know that the @types package is up to date with the latest version of the actual package when they are maintained separately?

For example there is npm package better-sqlite3 with no typescript definitions and then a separate type definition package @types/better-sqlite3. How user of the package can know that types match the current version of the package?

In this answer here it is said that "TypeScript types for JS packages is best effort and depends on Community interest in the package". This sounds a bit scary.

Improve this question
1

2 Answers 2

Reset to default
1

  1. If the package developers maintain the definitions themselves, there's no @types, d.tss are just building in package distro

  2. If there's @types, you may check the last update date of both packages (@types have Last updated in readme), the @types probably was correct at the time when it was last updated.

  3. If the @types is outdated, you may update if yourself and even publish on @types, that's what "TypeScript types for JS packages is best effort and depends on Community interest in the package" means

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

The types package shouldn't be maintained separately. The author of the package should be listing the corresponding types package as a dependency which means the correct version of the typing should come along when you install the top-level package.

REF: https://github.com/Microsoft/types-publisher/issues/81

Edit: As pointed out in the comments by @Gwydion, there are some packages that are community maintained outside of the originating package. A good example is:

https://www.npmjs.com/package/better-sqlite3

It would seem likely the following package is the correct types package:

https://www.npmjs.com/package/@types/better-sqlite3

But, it's not necessarily obvious either. It would be nice to have to signal to verify that this is the correct package.

Here is what I did:

  1. I visited the originating npm package page, taking note of the repository URL which is: https://github.com/WiseLibs/better-sqlite3

  2. I visited the repository URL of the type package, which is: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/better-sqlite3 (this URL was listed on the type package's npm page under Details)

  3. Open the index.d.ts file located there. At the top it lists: Project: https://github.com/JoshuaWise/better-sqlite3.

NOTE: https://github.com/JoshuaWise/better-sqlite3 redirects to https://github.com/WiseLibs/better-sqlite3 which matches what we found in #1 above.

Improve this answer

3 Comments

Thank you very much for your reply. I understand that many npm packages include typescript definitions. But I assumed that if package does not contain definitions then for some packages there are community maintained @types definition packages available that need to be installed separately. And was wondering, how user can be sure that these 2 match. Maybe there is something fundamental about this I am getting wrong.
For example there is package npmjs.com/package/better-sqlite3. There is no types as dependency in the package.json. But you can find a separate type definition package here npmjs.com/package/@types/better-sqlite3 Just wondering how user can be sure that the package and types-package match?
@Gwydion, thanks for the clarification. I've updated the answer as such. Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.