Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Definitely Not Versioned #7719
What's the recommended way to find a TypeScript definition file for a specific version of a library and a specific TypeScript version? (for example a definition file for lodash v2.4.2, which compiles with TypeScript 1.5 and above)
What I know is the following:
Some TypeScript definition files contain a comment at the beginning of the file, which mentions the version of the library this definition file refers to (e.g. AngularJS which specifies version 1.4+). Other TypeScript definition files don't mention anything in this respect - not even in the commit history.
Is there no reliable way to know what library version is covered by a TypeScript definition file?
The DefinitelyTyped repository has branches starting with 0.8 up to 1.4.1. I'm assuming that this represents the TypeScript version itself. Unfortunately it ends with 1.4.1. Therefore I assumed that TypeScript definition files on the master branch are valid for TypeScript 1.4.1 and above. Unfortunately this is not always the case - there are TypeScript definition file which are only valid for TypeScript 1.6 and above.
Is there no reliable way to know what TypeScript version is required for a TypeScript definition file?
What we're doing at the moment is storing commit hashes of TypeScript definition files that compile with the TypeScript version we're using currently (v1.5.3). While this is a pain, it kinda works. But since we usually don't know, which library version the definition file is for, we're just hoping for the best. This doesn't sound like a promising and reliable process though.
An answer along the lines "there is no recommended way, apart from being up-to-date with TypeScript and libraries is the best you can do" or "it depends on the library" are perfectly acceptable answers. :)
I'm mainly asking because I want to be sure that I'm not missing something very obvious here...
@mhegazy Yes that is clear.
The issue here is that there is no clear way to see for which version of a library the typings are for. The version numbers of the
The only indicator you get is the file header (which is also not always present or even up-to-date) that contains the version number (usually only major) which makes it really hard to do an upgrade for a specific version of a library. For the example with jquery above, the header comment says it is compatible with jQuery 1.10.x/2.x but does not mention 3.x at all:
The idea of being always up-to-date is great, but seldom doable in a large project or company.
There is just too much of guesswork and trial and error involved for my taste. I know this is a community project and kept alive by volunteer contributors with tight resources but I do not understand why there is no guideline on versioning.
Typescript is supposed to speed up development by eliminating the problems and bugs that happen in vanilla JS due to its untyped nature but with incorrect typings and some that do not match at all for the major version this is just as bad.
I totally agree with this. All the tutorials say how easy it is to use DefinitelyTyped but that's only if you're grabbing the latest version of a package and you grab the latest typings and they happen to work. If you need the typings for an older version of a package or the typings aren't up-to-date, you're SOL. The obvious way to do it would be for me to be able to say in
At the time of writing,
We could potentially generate a change log for each package based on the commit messages. What'd be the best place to put it, and what kind of format should it have?
Sorry for bumping this, and this might be more suited towards
Is there really no mechanism to control the Typescript version? I've ended up indirectly installing some packages from @typed that are breaking / muddling my build.
Some library that I'm not consuming directly recently added a definition file using Typescript 3 features. It just so happens that this library is in the dependency graph of a linting tool I'm using, so after doing
Am I doing something wrong? I can do
Correct me if I'm wrong, but the compiler always parses all the definition files on node_modules/@types, doesn't it? There's no way of telling it to ignore certain ones.
Maybe @types files should adopt some mandatory metadata that the compiler could parse, like the TS version. Then tsc could throw a warning or just ignore files not compatible with your compiler.
@rjimenezda a few things
You can add a
From a configuration side, IMO the package author was wrong to include a
In the future we'll be able to use the
Thanks for the answer @RyanCavanaugh, much appreciated.
I also think they should've done this differently (perphaps not a minor, but a major upgrade), but to each their own.
That feature looks very promising. So for instance, tsc 3.2 will ignore declaration files that are not compatible with it? (Like a future 4.x).
As for the problem itself, I'll try to lock down this library version or manually specify all the types we're using (as a temporary fix)