Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definitely Not Versioned #7719

Open
snoopcheri opened this issue Jan 21, 2016 · 20 comments

Comments

@snoopcheri
Copy link

commented Jan 21, 2016

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:

Library Version

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?

TypeScript version

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.

@snoopcheri

This comment has been minimized.

Copy link
Author

commented Jan 25, 2016

Anyone?

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

@alainsahli

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2016

+1 👍

@sir-marc

This comment has been minimized.

Copy link
Contributor

commented Jan 14, 2017

No one?

@simonalbrecht

This comment has been minimized.

Copy link

commented May 4, 2017

+1 👍

@mhegazy

This comment has been minimized.

Copy link
Contributor

commented May 4, 2017

@types packages have TS version tags on them. if you want a specific version of the compiler then fix your dependency on @ts2.0 for instance.

@simonalbrecht

This comment has been minimized.

Copy link

commented May 5, 2017

@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 @types package only very rarely match the version of the dependency you're pulling the typings in. For example, jquery@3.2.1 (which is the latest version at this time) is paired with @types/jquery@2.0.42.

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:

// Type definitions for jQuery 1.10.x / 2.0.x

Source: jquery/index.d.ts


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.

@KodingSykosis

This comment has been minimized.

Copy link

commented Jul 10, 2017

Over a year and still no solution? Why does the definition file have independent versioning? Isn't it really just a contract? I currently have an issue where my definition file for jquery doesn't match the version we're actually using.

@erlangp

This comment has been minimized.

Copy link

commented Sep 9, 2017

+1

@jez9999

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2017

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 package.json:

...
  "dependencies": {
    "uuid": "^3.1.0"
  },
  "devDependencies": {
    "@types/uuid": "^3.1.0"
  },
...

At the time of writing, uuid is at 3.1.0 and @types/uuid is at version 3.4.2. Why isn't it at 3.1.0? This versioning should be strictly enforced.

@OliverJAsh

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2018

I would really like to see changelogs for each package. Could that be considered as part of this?

@katesowles

This comment has been minimized.

Copy link

commented Mar 7, 2018

Not having some method of tracking version changes (releases? changelog? SOMETHING?) is absurd. Hoping this gets some attention.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

git log ?

If anyone wants to drop a CHANGELOG.md file in a given types folder and try to get PRs to keep it up to date, that'd be great. We can put it in the auto-generated README too.

@katesowles

This comment has been minimized.

Copy link

commented Mar 7, 2018

@RyanCavanaugh Running git log is not a helpful solution in this case. I can see the commit list plainly enough from the github, but what about that do you think is akin to a changelog? Commits still are not tied to a specific release and even if they were, a user would have to wade through the entire repo's ~43k commit's to find the ones relevant to the definitions they're trying to update. Much of the OSS community understands this and so they include a changelog SOMEWHERE in their online documentation so users can avoid this sort of laborious digging.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

a user would have to wade through the entire repo's ~43k commit's to find the ones relevant to the definitions they're trying to update.

?

C:\github\DefinitelyTyped\types\jquery>git log --pretty=oneline --abbrev-commit .
bef4d2b27d Enable "esModuleInterop" in all tsconfigs (#23354)
37685e11dd Add tslint disables for no-const-enum (#23134)
32a23a8139 [jquery] Update to jQuery 3.3. (#23095)
29c6e0f81a [jquery] Support projects without ES2015.Iterable. (#22766)
1e7989f8ce [jquery] Overriding the beforeSend function for AjaxSettings and UrlAjaxSettings to indicate a more appropriate settings parameter type Fixed errors when running lint
3f7bbeaa51 Miscellaneous lint fixes (#21116)
4e52c4dea6 jquery: Fix lint (#20965)
19f89399e4 Ensure every package has a tslint.json (#21009)
fdd6cc3a35 [jquery] `after()`, `append()`, `before()`, and `prepend()` can accept an array of JQuery (#20319)
42cf3abe63 [jquery] Add ajaxSettings property. (#20433)
947a8fb761 Enable strictFunctionTypes (#20373)
32ae9f623b Fix test failures
b8ea87c68e Strict function variance fixes round 1
924fafffc0 Fix remaining lint errors (#19166)
44a9d083d4 Merge pull request #18638 from leonard-thieu/jquery-promise
5d6c651a1a Apply stricter lint rules (#19063)

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?

@erlangp

This comment has been minimized.

Copy link

commented Mar 8, 2018

maybe:
[lib_name] [lib_version] [typed_version]
[Name] [0.0.0] [0.0.0]
? @RyanCavanaugh

@rjimenezda

This comment has been minimized.

Copy link

commented Dec 14, 2018

Sorry for bumping this, and this might be more suited towards tsc.

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 npm install, their @types showed up in my node_modules. Now my build complains / is broken because of the Typescript 3 features.

Am I doing something wrong? I can do "skipLibCheck": true to ignore those, but it's not granular at all.

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.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Dec 16, 2018

@rjimenezda a few things

You can add a types list to your tsconfig.json, though this does mean you'll have to manually specify "all but" the problematic one.

From a configuration side, IMO the package author was wrong to include a @types dependency in their package, because it creates exactly this situation.

In the future we'll be able to use the typesVersions feature (see microsoft/TypeScript#26568) so that older compilers see other versions of type definition files, but that feature only provides compat for TS 3.1+ (IOW eventually this won't be a problem anymore)

@rjimenezda

This comment has been minimized.

Copy link

commented Dec 17, 2018

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)

@Machiaweliczny

This comment has been minimized.

Copy link

commented Mar 15, 2019

Can't type packages have matching library version defined in peerDependencies?

@aaronbeall

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I really like the idea of having a generated CHANGELOG.md file. Any update on that @RyanCavanaugh ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.