Typing badges

I was thinking of creating a website for badges, in the spirit of sites like http://david-dm.com, for providing badges that inform the user whether the package has typings associated with it. This would promote the creation of typings for packages. Sounds like a good idea? If so, I'd be able to work on it this summer holiday.

[blakeembrey]

@samvv I love it, great idea! 👍 We could actually use shields.io api for now.

For example:

Indeed we can, and thanks! :D I've already begun working on a prototype which is uses some of shields.io's code. The most difficult part is downloading a specific version of a NPM package to inspect its contents, but I was thinking ... if we're able to do that, there's not much in the way to TypeDoc it, too.

By the way, this might be a good moment to ask how typings is doing on its website, because I might be able to merge both projects.

[blakeembrey]

Let me know if there's anything I can do to help 😄

No problem, thanks, I've already got a basic version up and running 😄 if you type a url like localhost:3000/lodash an image appears which tells you if the repository supports typings. The code is not the prettiest around but it works. It is here: https://github.com/samvv/typings-website-api. Now starting to work on Typedoc for issue #16.

One thing that needs to be set: how should the badges look? I really like your idea of the check sign, I'd definitely vote to go with that, but what should the text be?

There is also another thing you might be able to do, though it is a bit strange to ask ... could I become a member of the typings organization? That way I can transfer my repositories to you guys if you like it.

[blakeembrey]

That's pretty neat! Have you seen a way to easily sync changes every 10 minutes or hour or so? I think it'd be great to not have to do it on demand. We could then combine this code with the existing Typings API 😄

For the badges, I feel like "TypeScript Definition" was the most clear out of the ones I tried above. The nice thing about those is that I wasn't even thinking in the context you were, I was thinking about a badge people can put on their READMEs (like the build status, etc).

You can definitely be a member of the organisation, but I haven't enabled transferring repos in this particular org. If you'd like to collaborate, you'd be welcome to make a PR and I can add you to the API repository. Someone will need to host the service after all 😄

Even better: when I'm finished it will hopefully cache the result indefinitely. And "TypeScript Definition" sounds good to me 👍

And OK, I'll look into merging with the API server when I'm finished.

[blakeembrey]

Right, I was looking through it - but it's currently all in-memory. The implementation won't be able to be in-memory when we finally deploy, there's some 100,000+ possible modules (not counting 404s). It'd also be nice not to be reliant on the NPM API - they might rate limit hits (which our service would die then), or even go down sometime themselves (either from our side or theirs). It also means all queries are dependent on NPM network speed the first time, which we don't have any control over. Basically, I'd like to avoid it if possible - especially since we might want to do things like provide a native modules with typings search feature. Also, a typings file might be removed in the future (which caching indefinitely won't catch until restart).

Hmm indeed; I was planning to add data persistence in a later stage. Would Redis be a good idea? Since we are just storing key-value pairs based on versions, this looks to me like the best choice (but I'm not an expert when it comes to databases).

And correct me if I'm wrong, but are NPM releases not static, i.e. they cannot be changed? In that case, we can cache as many results of the versions of the package as we want for as long as we want to.

[blakeembrey]

They are static, but I thought you were currently checking the latest package? Since it's all on-demand, that would result in hitting the NPM API every time (in case a new release has occured) or after a cache timeout (E.g. 24 hours). It's reasonable, but it would be great to have a search ecosystem where we can find NPM packages made for TypeScript 😄

I fully agree 😄 I am currently working on caching the results with a configurable timeout, will keep you updated!