CODEWITHSUNDEEP
typescriptpackage.jsontypescript-typings
nevster
nevster

Reputation: 6465

How is versioning supposed to work with the new Typescript 2 @types?

Instead of using typings, with Typescript 2 we're supposed to install dependencies in the @type namespace via npm. But the versioning seems to be a mess.

For example, if I do an npm view urijs, I see these versions:

 '1.17.1': '2016-02-25T10:06:35.269Z',
 '1.18.0': '2016-04-30T09:27:13.484Z',
 '1.18.1': '2016-05-29T16:43:29.257Z',
 '1.18.2': '2016-09-25T19:59:43.684Z',
 '1.18.3': '2016-11-17T22:13:15.243Z'

If I do an npm view @types/urijs, I get this:

 '1.15.24-alpha': '2016-07-04T01:27:50.730Z',
 '1.15.25-alpha': '2016-07-08T21:42:31.607Z',
 '1.15.26': '2016-07-14T16:18:54.580Z',
 '1.15.27': '2016-08-02T16:14:09.235Z',
 '1.15.28': '2016-08-19T15:45:23.543Z',
 '1.15.29': '2016-08-25T19:04:03.083Z',
 '1.15.30': '2016-09-19T18:17:20.887Z',
 '1.15.31': '2016-10-05T21:04:18.199Z'

Say I have a dependency on [email protected], how am I supposed to know which @types version to get? Do I have to resort to looking at the dates and hoping I get a good one?

Is this just a case of the developer "doing it wrong"? Ie is the plan that developers release a matching @types version with the same number, preferably at the same time?

Upvotes: 2

Views: 400

Answers (1)

Daniel Rosenwasser
Daniel Rosenwasser

Reputation: 23443

Generally speaking, for any major.minor.xxx.xxx version of an @types package should reflect the latest major.minor.xxx.xxx of the package itself. So if it were published, 1.18.49 on @types would ideally reflect 1.18.3 of the package itself.

It may just be the case that there've been no updates between version 1.15 and 1.18 that required an update to the .d.ts file. It may also just be someone "doing it wrong" like you said.

You should definitely feel free to update the .d.ts version on the types-2.0 branch on DefinitelyTyped.

Upvotes: 2

Related Questions