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:

• export default function () {, export default class {}, export default () => {} - (The first two of these anonymous defaults were giving errors, but this is now fixed.)
• The named variety: export var a = function () {} (export {name} is already implemented)
• Checking scopes
• TSInterfaceDeclaration (see require-jsdoc: contexts and publicOnly lead to false negatives #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.

[brettz9]

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