You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have come across a few use cases in eslint-plugin-jsdoc for allowing users to provide their own esquery contexts to indicate language features where comment blocks should apply.
For one example, there is a user who would like to require jsdoc blocks above a getter/setter pair, but not above each getter/setter. While they can define their allowable contexts like:
We have come across a few use cases in
eslint-plugin-jsdoc
for allowing users to provide their own esquery contexts to indicate language features where comment blocks should apply.For one example, there is a user who would like to require jsdoc blocks above a getter/setter pair, but not above each getter/setter. While they can define their allowable contexts like:
...this doesn't perform checking to ensure that the getter preceded by a setter (or vice versa) that we are avoiding including is of the same name.
I would think that some kind of wildcard + backreference scheme such as:
'MethodDefinition[kind="set"]:not(MethodDefinition[kind="get"][key.name=(*)] + MethodDefinition[kind="set"][key.name="\\1"])'
...might help us solve these kinds of problems (the wildcard being necessary as the user doesn't know the method names in advance).
(Another use case we have currently is for only requiring docs on the top of a sequence of adjacent
TSDeclareFunction
's.)The text was updated successfully, but these errors were encountered: