`publicOnly` to handle more export formats

[brettz9]

The new publicOnly of require-jsdoc seems not to be able to handle exports of any of these forms (with esm: true) as these fail to report missing jsdoc:

• [x] export default function () {, export default class {}, export default () => {} - (The first two of these anonymous defaults were giving errors, but this is now fixed.)
• [x] The named variety: export var a = function () {} (export {name} is already implemented)
• [ ] Checking scopes
• [x] TSInterfaceDeclaration (see #492)

With some strange structures like the following, besides the fact of adding support, it would let us remove some /* istanbul ignore next */ directives (see #286 , an issue interrelated with this one), but this won't pass now, and would need to support scopes (which the code comments indicate is not yet supported) and may in some cases be more complexity than its worth (e.g., parsing template properties):

var a = {};
if (true) {
  a = {q: function () {}};
}
var test = a[`q`];

class Clss {}
var test2 = a[Clss];

export { test, test2 }

@Extersky

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Extersky]

As the first two items are fixed, I can take a look at the object keys, scoping and writing test cases for uncovered lines of exportparser file. Scoping likely requires more strict tracking of ECMAScript specification than the resolver does so far, to not give wrong results. Implementing static analysis of if blocks also opens other questions, such as, what values should be statically analyzable.

[brettz9]

Sounds good... Re: object keys, FWIW, while there are probably better examples, I happened to find in exploring the uncovered lines a little, that, per my example, putting a template and function in the position of a key handled a couple of those uncovered lines (now exempted from coverage)--as unusual as the latter is.

[orlov-vo]

What about catch export simple variables with jsdoc/require-jsdoc?

export let someBool = false;
export let someString = "foo-bar";
export const someObject = {};

[brettz9]

@orlov-vo : You can get this by using the contexts option:

{
    contexts: ['ExportNamedDeclaration']
}

However, this cannot be used with publicOnly, which insists on functions or classes.

So, if you use this approach, you will need to whitelist the other contexts where you wish support, e.g., FunctionExpression, so if you want jsdocs required for all possible exports, I think the following should be enough to get them:

{
    contexts: [
        'ArrowFunctionExpression',
        'ClassDeclaration',
        'ClassExpression',
        'ExportNamedDeclaration',
        'FunctionDeclaration',
        'FunctionExpression'
    ]
}

[orlov-vo]

@brettz9 thank you! It's work for me

[apowers313]

I have a similar issue with exporting a class. My config is:

"jsdoc/require-jsdoc": [
    "error", {
        enableFixer: false,
        publicOnly:  true,
        require:     {
            ClassDeclaration:        true,
            ClassExpression:         true,
            FunctionDeclaration:     true,
            FunctionExpression:      true,
            MethodDefinition:        true,
            ArrowFunctionExpression: true,
        },
    },
],

This flavor of exporting a class triggers Missing JSDoc comment on the method but not the class:

class Utility {
    mthd() {
        return false;
    }
}

module.exports = Utility;

This flavor of exporting a class triggers Missing JSDoc comment on the class but not the method:

module.exports = class Utility {
    mthd() {
        return false;
    }
};

[brettz9]

@apowers313 : I have confirmed this is a bug, and though no guarantees on my getting to it, please file as a separate issue so there is a greater chance it can be discovered and given priority as a bug. I'd like to keep this issue now limited to general types of detection rather than AST-node-type-specific problems. Thanks!

[brettz9]

I think the most critical items are discoverable, so closing.