Runtime analysis doesn't work well for modular or sandboxed libs like YUI
Opened this issue · 1 comments
Awesome project! I love the idea of making different JS lib APIs easily explorable on a single site.
Providing good support for modular or sandboxed libraries like YUI is going to be difficult (maybe even impossible) using runtime analysis, though. For instance, right now, jsapi only lists static members of the YUI global object, but virtually all of YUI's useful core APIs exist inside an instance-specific function sandbox, so they aren't visible by default. In addition, YUI's core is actually very small; most of the library's functionality exists in modules that are loaded on demand. Getting those modules' APIs into jsapi using runtime analysis would require loading and inspecting each one.
If you're open to considering alternative discovery mechanisms in addition to runtime analysis, the YUI website exposes a JSON API that provides names, parameter lists, summaries, and source locations for all classes and class members of all official YUI modules (warning: there are tons of them!). jsapi could consume this API if you're interested.
The following API endpoint will return all the info you'd need except the source files themselves (warning: the response is over 300KB gzipped; there's a lot of info there): http://yuilibrary.com/api/v1/classes
The source files can be found on the Yahoo! CDN at http://yui.yahooapis.com/{{version}}/build/{{file}}, where {{file}} is the file path returned from the API. The Google CDN, which jsapi currently uses, will not host YUI versions after 3.3.0 (the current version is 3.4.1).
Sorry for not responding sooner.
When I have some free time I hope to look at alternatives to runtime analysis. Using the current technique and loading separate modules might be viable though. Thanks for the details on the CDN URI signature too!