This repository was archived by the owner on Dec 4, 2018. It is now read-only.
Avoid erring with "event:" within @param
and @returns
tags and any other allowed contexts
#221
Labels
What version are you using?
That on https://eslint.org/doctrine/demo/
What JSDoc comment were you trying to parse?
I used "event:" as part of a string comprising an event name reference within
@param
:What Doctrine options were you using (sloppy, unwrap, etc.)?
No options except toggling the demo's "recoverable" option with different results apparently because it normally errs (whereas it shouldn't).
What happened? Include output if possible.
It gives:
...though when "recoverable" is checked, it gives:
I get similar problems if adding the event to
@returns
instead of@param
.What did you expect to happen?
I'd expect the output to look more like the "recoverable" option (or at least how it should be if "event:" weren't a problem inside of
@param
).The JSDocs (for @listens) states:
So "event:" should be permitted within references to events (including
@param
) without complaint, at least at preceding a property name at the beginning of namepaths (#
,.
, or~
for JSDoc 3, and apparently-
, if supporting JSDoc 2), so, e.g.,MyClass#event:foo
orMyClass~event:foo
.The code above was even taken from http://usejsdoc.org/tags-listens.html (with
@returns
added to avoid the error about it missing@returns
). This code usesevent:
within a@param
, and if this is removed, doctrine shows no difference with "recoverable" checked or unchecked (and it includes more info such as thelistens
andreturns
results), i.e., apparently ceasing to err (the@listens
use is not problematic).Even if one could work around this by avoiding "event:" within event names, it is not only explicitly permitted by JSDoc but is helpfully descriptive in distinguishing such events from other object references.
Moreover per http://usejsdoc.org/tags-event.html , it appears it may be even required in some locations (and is explicitly permitted in the signature):
The text was updated successfully, but these errors were encountered: