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

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.

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.



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?

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.