Module support

[victorwoo]

It's common scene in JavaScript world to publish script as module pattern (AMD, Require.js, etc.). Will jsduck support module pattern?

[nene]

But what do you mean by supporting it? How would you expect JSDuck to behave? Please be more specific. Like: given input X I would expect output Y, but JSDuck gives me Z instead. On Apr 16, 2014 5:11 AM, "victorwoo" [email protected] wrote:

It's common scene in JavaScript world to publish script as module pattern (AMD, Require.js, etc.). Will jsduck support module pattern?

— Reply to this email directly or view it on GitHubhttps://github.com/senchalabs/jsduck/issues/553 .

[JohnnyFee]

@nene Maybe you can refer to JSDoc supporting for module http://usejsdoc.org/howto-commonjs-modules.html.

[nene]

At the moment one can achieve this by documenting the module as a @class. So if you have module "foo/bar" with functions doThis() and doThat(), you could document the module as @singleton @class foo.bar with the corresponding methods. Not quite precise, but that's the closest you can get now.

I have no concrete plans for more special module support right now. It's definitely something to consider for the future, but at the moment it's just some vague pieces of ideas lying on the table. On Apr 16, 2014 10:28 AM, "Johnny Fee" [email protected] wrote:

@nene https://github.com/nene Maybe you can refer to JSDochttps://github.com/davidshimjs/jaguarjs-jsdocsupporting for module http://usejsdoc.org/howto-commonjs-modules.html.

— Reply to this email directly or view it on GitHubhttps://github.com/senchalabs/jsduck/issues/553#issuecomment-40570635 .

[Krinkle]

A module structure separate from the class/member hierarchy would fulfil two main use cases I see:

1. When browsing around the regular class/member hierarchy, or when following a permalink to a method, one can see which module provides it. While in many cases the encapsulating class and/or the file it was defined it will tell you (e.g. member mw.user#getName is from mediawiki.user.js part of module mediawiki.user). But there are also cases where a class is augmented by a module (e.g. mixed in, like jQuery plugins) so things start to get less obvious. E.g. jQuery#firstTabIndex is from jquery.tabIndex.js part of module jquery.tabIndex. In that case the file name was still a good indication, though that's only by convention and feels wrong to derive from that (not everyone names files after full names of their modules). Plus, you get modules composed out of many separate files (especially for libraries that are built from source files, you'd probably want to run jsduck on the raw files, not the compiled file for distribution). E.g. method ve#log from ve.debug.js part of module visualEditor.base. And ve.Node#getOuterRange from ve.Node.js part of module visualEditor.core.
2. Listing all classes/members provided by one module. E.g. a jQuery plugin that provides two or three different methods. Having those on one page would be quite useful. Right now I work around this by declaring a fake class called jQuery.plugin.foo and ending the file with /** @class jQuery @mixins jQuery.plugin.foo. Thus providing me with two views to the methods exposed there (mixed in on the jQuery class page and at the plugin's class overview). The limit of this hack is reached though when a plugin attached methods on multiple classes or when it (by itself) provides more than one new class.