Module discovery

[guybedford]

I've had a couple of issues with module discovery recently, and I think it could be worth discussing some options along these lines.

Basically, I couldn't find a routing library from google searches meeting my needs, so wrote my own. This turned out to be completely unnecessary as I finally noticed there is one by Miller Medrios that turned out to be mostly identical.

I think focusing on discovery would close the loop on having the requires system and package management in place. Because if I can find, and easily install modules, which are being loaded in a common way then that covers everything needed to be writing modular javascript.

It would also significantly contribute to the adoption of volo and hence requirejs, if such a system could show me what's available immediately.

The github module discovery isn't good enough for finding modules in the first place. Simply put, we need a way of browsing modules under categories like the jam browser offers. Separated by categories like Frontend / backend. Then breaking down such as 'ajax', 'routing', 'mvc', 'dom', 'canvas' etc. Their categories are quite a good start. (see http://jamjs.org/packages/#/)

I had a similar problem finding a simple modular ajax library. If there was a generally accepted ajax library, which I could see was being used by volo users (stats for volo add would provide the much-missing download count functionality git lacks), then I would have based my plugins on this. But for now I still can't properly see what's out there so am forced to roll my own stuff.

In short, I think a categorised module browser for volo modules would be incredibly useful.

[James Burke]

Discovery is a difficult problem. I'm open to ideas, but I do not find
having tags sufficient. It may give you a better place to start,
although I do not think much. Once the repos get to the size of say,
npm, there is just a whole bunch of noise, and knowing what is
actually good in there requires doing google searches/specific repo
investigations.

I would think curated lists would be more effective. GitHub has some
search capabilities:

https://github.com/search?q=routing+amd&repo=&p=1&type=Repositories&l=JavaScript

I am sure it is not sufficient though. I'm open to ideas though. One
of the goals was to not need extra server infrastructure and require
people to buy into another place to publish. So I would want to
balance those design goals.

I believe yeoman as an opt in feedback collector option, so things you
do with yeoman are sent back to basically a metrics server. That may
be something worth looking into, as a way to get data to build these
kinds of lists. I'm open to helping someone out if they want to
explore that option. I would be OK setting up a server for that, since
it does not require extra work for publishers or users, but it does
mean collecting client metrics, which may be a turn off for some
folks. I do like the idea of metrics though. Just want to do it in a
respectful, privacy-aware way.

James