Eslint-plugin-jsdoc: @private shouldn't require anything

[henriklundgren]

/**
 * @private
 */
function myPrivateFunc() {}

[gajus]

Fix welcome.

[brokentone]

More details about what "anything" is would be helpful. All rules should be skipped? There is a particular error for the single parameter which should be skipped?

[henriklundgren]

@brokentone I would think that all rules should be skipped. @private is by definition excluded from documentation and shouldn't be linted (or at least no reason to lint it).

[brokentone]

Sorry, I suppose I'm late on the draw here. I would tend to disagree with this reasoning. jsdocs are not just for public users, they can also be useful internally. I for one would be confused of I lost all validation if I added the @private param -- minimally this would need clear documentation.

That said, were this a desired feature for people, perhaps it's a global setting which gets applied to all rules

[henriklundgren]

I would say that jsdoc is for public documentation.
Internal doc probably better suited with line comments.

/**
 * @function
 * @param {Object} x - awesome object
 */
function getPoint(x)  {
  const result = ccalulcatePoint(x);
}

// named it dubble cc to avoid monsters
function ccalculatePoint() {}

[gajus]

I reverted the changes until broader consensus is reached. I agree with @brokentone that:

jsdocs are not just for public users, they can also be useful internally. I for one would be confused of I lost all validation if I added the @private param -- minimally this would need clear documentation.

[zakkudo]

I hit the same issue, but my assumption is that this should be configurable. jsdoc is for public documentation, but @private is meant to keep something from being documented publicly. Whether that means no validation is a separate issue.

In my case, I would prefer not to have to document params when @private has been set. This would mean adding an extra option to the params validation and no the @private validation itself.

[zakkudo]

If you want me to make a proof of concept I'm open to that. This change as it is also probably breaks a lot of user exceptions of how validation works which is bad. Extra options for other validation to be ignored when @private is set won't break current validation.

[brettz9]

I've started a branch for this (via an optional (off by default) ignorePrivate setting), but waiting on a bunch of PRs to avoid merge conflict troubles.

[gajus]

:tada: This issue has been resolved in version 6.0.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: