No documentation appearing when class is included using require.js or browserify.

I've tried to correctly follow JSDoc guidelines for all of my code and it looks like I've properly documented my constructors so that WebStorm is able to recognize arguments:
jsdoc working.png

But for some reason, when I export the classes as so that they can be required elsewhere, they are no longer recognized anywhere for what they are:

export fail.png

As you can see by the syntax highlighting, it's also no longer automatically recognising it as a Class / Constructor.

Am I missing something in the way I should be exporting the class or documenting the export that's confusing WebStorm when a user requires my library? The require statement itself is working, and WebStorm has no trouble navigating to the source file referenced in the require statement (`'./YLTProfile'`), but the definition information is completely lost for some reason.

4 comments
Comment actions Permalink

WebStorm doesn't yet support documentingAMD/commonJS stuff (https://youtrack.jetbrains.com/issue/WEB-11493)
For  now the suggested approach is using @class tag to annotate exported  objects/functions, and then use inline JSDoc for parameter type - see https://gist.github.com/ulitink/9757354

1
Comment actions Permalink

Thanks for taking a look at this. As you can see above, I did add the @class annotation to the exported object as well.

Just now I tried remove the unsupported @module annotation above it and add the @class name alongside, like in your linked example, but Webstorm still doesn't recognise it as a class once it's been required:

/** @class YLTProfile */
module.exports = YLTProfile;
// elsewhere
var
YLTProfile = require('./YLTProfile');
var
thing = new YLTProfile(); // I get no help here


(The above code appears to be a standard node class pattern: http://book.mixu.net/node/ch6.html)
Funny enough, if I wrap the class in an empty object Webstorm seems to have no trouble identifying it as a class/constructor, even without any annotations about it being a class:

/** Exports a namespace */
module.exports = {
  YLTProfile: YLTProfile
};

// elsewhere
var
dummyObject = require('./YLTProfile');
var
thing = new dummyObject.YLTProfile(); // I get a list of args here


I don't want to have to wrap all my exports in dummy empty objects though if I don't have to. It makes them awkward to use.

0
Comment actions Permalink

Here's another screenshot illustrating how it can see the class definition and I can ctrl+click to  navigate to it (definition seen on the right), but it's highlighted  white and offers no context or constructor parameter information about  the class.

jsdoc.png

I posted about my problem on Stack Overflow and someone else has mentioned that they have no problem having the identifier treated as a Class when they imitate my example. Is there possibly a configuration value or global library that handles this that I could be missing?

0
Comment actions Permalink

I've also been *really* wanting this feature for a good year now.

I think there are a few parts to this.

1) Be able to understand JS files as having their own function scope. The files are getting wrapped into modules. Individually, they simply lack the module boilerplate. So have a way to wrap the contents of JS files with module boilerplate. Right now, files are all interpretted as global.
2) Understanding constructors as more than {Function}. See WEB-13845.
3) A 'magic' require()/etc which can map and return actual modules, not just a @returns {*} JSDoc stub.

0

Please sign in to leave a comment.