This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
add support for @param tags w/o a type #16
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
My bad—I completely forgot to run all the tests (only ran my test!). I will fix momentarily. |
These tests were actually covering the same scenario as the "param typeless" test; but they were expecting failures (doctrine should now handle this case).
This is admittedly pretty hacky. The fundamental problem is that the original code was written to enforce that @param tags must have types. This actually isn't the case; so to fix that I added logic to check if a @param has a "type" but no name, to cover this case: @param foo In the above example the param would initially be parsed as having a "type" of foo and no name; my fixer-up logic switched these around so foo becomes the name and the type becomes null. But now here is a problem case: @param {string} [foo] The above is a "sloppy" declaration where foo is an optional param w/ a type of string. Problem is that w/o the sloppy option set, parseName will return undefined for name, which will trigger the logic previously described for fixing the case w/ typeless params. My solution is to handle this specific scenario at the end of next(): check for a tag w/ a name, no type, and a description starting with '['; if this pattern is found, revert things to the way they were. Hopefully @Constellation can come up with a (much!) better approach for dealing with all this.
dtao
added a commit
to dtao/autodoc
that referenced
this pull request
Jan 6, 2014
This is to handle typeless params, until eslint/doctrine#16 is merged.
|
I believe this PR should be good to go now (w/ caveats: see the epic comment in that last commit). |
|
Very nice. Merging. |
Constellation
added a commit
that referenced
this pull request
Jan 6, 2014
add support for @param tags w/o a type
|
Thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
According to the JsDoc docs, the
@paramtag does not require a type. So this should be legal:This patch updates doctrine to parse the
@paramtag just fine in this case, w/ atypeofnull.