Skip to content

Report error for duplicate @type declaration in @typedef #17442

Description

TypeScript Version: master

Code

/**
 * @typedef Name
 * @type {string}
 * @type {Oops} - this is dropped and we stop parsing the @typedef
 */

Expected behavior:

Error.

Actual behavior:

No error.

Activity

  1. added this to the milestone on Apr 12, 2018
  2. noamyogev84 commented on Oct 2, 2018

    @noamyogev84

    Hi Mohamed Hegazy (@mhegazy) can I try that one?

  3. sandersn commented on Oct 2, 2018

    @sandersn
    Member
  4. noamyogev84 commented on Oct 2, 2018

    @noamyogev84

    Thanks Nathan Shively-Sanders (@sandersn). can you please share some code pointers?

  5. sandersn commented on Oct 2, 2018

    @sandersn
    Member

    You'll want to start in parseTypedefTag in parser.ts. There is a section of code that checks for the child @type inside @typedef:

    while (child = tryParse(() => parseChildPropertyTag(indent))) {
        // ...
        if (child.kind === SyntaxKind.JSDocTypeTag) {
            if (childTypeTag) {
                break;
            }
            else {
                childTypeTag = child;
            }
        }
        // ...
    }

    As you can see, in case of duplicate @type tags, the code just breaks out of the loop with no error. Add a call to parseErrorAtCurrentToken before breaking out of the loop. DiagnosticMessages.Unexpected_token is probably good enough for the message, but you can add a new one in diagnosticMessages.json if you want. Maybe "Unexpected tag '{0}'." or "Duplicate tag '{0}'."

    For adding tests, follow the directions in CONTRIBUTING, except that you should add your test in ts/tests/cases/conformance/jsdoc, and you will need to explicitly allow JS at the top:

    // @allowJS: true
    // @checkJS: true
    // @noEmit: true
    // @Filename: bug17442.js
    // ... actual test goes here ...

    Daniel Rosenwasser (@DanielRosenwasser) any opinions on what the error message should be?

  6. noamyogev84 commented on Oct 3, 2018

    @noamyogev84

    Great I'm on it.

  7. noamyogev84 commented on Oct 5, 2018

    @noamyogev84

    Hi Nathan Shively-Sanders (@sandersn),
    Following your directions does not produce the wanted result, or maybe i'm missing something. (No error message is outputted by the compiler)
    I'm debugging tsc.js and it seems like parseErrorAtCurrentToken does not affect the rest of the method.

    "Planting" an arbitrary syntax error in the above example does produce error, but I still can't figure out where it's being handled. Do you have any idea what's missing?

  8. noamyogev84 commented on Oct 13, 2018

    @noamyogev84
  9. nisha-kaushik commented on Jan 18, 2019

    @nisha-kaushik

    Can I try this one?

  10. DanielRosenwasser commented on Jan 18, 2019

    @DanielRosenwasser
    Member
    A JSDoc '@typedef' comment may not contain multiple '@type' tags.
    

    Bonus points on providing a related span on the first tag if it's not too hard:

    The tag was first specified here.
    
  11. DanielRosenwasser commented on Jan 18, 2019

    @DanielRosenwasser
    Member

    Nisha Kaushik (@nisha-kaushik) go for it.

    Not sure if Noam Yogev (@noamyogev84) is still looking at this but the issue they were running into might've just been running tests in a .ts file or an unchecked .js file.

  12. noamyogev84 commented on Jan 19, 2019

    @noamyogev84
  13. locked as resolved and limited conversation to collaborators on Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugA bug in TypeScriptDomain: JSDocRelates to JSDoc parsing and type generationDomain: JavaScriptThe issue relates to JavaScript specificallyGood First IssueWell scoped, documented and has the green lightHelp WantedYou can do this

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions