Validating JavaScript code with JSDoc types annotations

Today’s post is about a nice feature set (many of you have been using for a long time) and its recent improvements. I’m talking about static type checking when type of parameter or variable on the left side of assignment or function return type is explicitly specified in JSDoc annotation. For 5.0 release we’ve supported Google Closure types syntax, so that quite complex situations can be handled more accurately and conveniently.

To start with let’s consider the most basic situation:
@param

Every constructor function “becomes” a type and its name can be referenced inside JSDoc tags.
Array typesArray of elements of some type could also be specified with [] (for example, Point[]).

Return type is checked inside function and when its call result is used somewhere.
Union type

Type checking may even be helpful without explicit types annotations.

And this is my favorite case. You can specify callback’s ‘this’ and parameter types, and they will be known in passed anonymous function. Note that completion processor uses nearly the same info as type checking, so if type is specified in JSDoc annotation, properties of that type will be shown in completion list.

You can always change the type mismatch highlighting style in Settings | Inspections | JavaScript | General | Type mismatch problem to get it more emphasized or disable it at all.

Develop with pleasure!
– JetBrains Web IDE Team

This blog is permanently closed.

For up-to-date information please follow to corresponding WebStorm blog or PhpStorm blog.

 
This entry was posted in Cool Feature, PhpStorm, WebStorm and tagged , , , , . Bookmark the permalink.

11 Responses to Validating JavaScript code with JSDoc types annotations

  1. Dylan Greene says:

    I love this feature but it sometimes “guesses” the wrong arguments which leads to unnecessary confusion.

    Is there a way to override the jsdoc it guesses with the right one?

    An example, using Node/Express:


    Server.get('/signin', signIn);

    It thinks .get has no parameters because in Node’s net.js it doesn’t have any (it probably uses arguments to get the parameters).

  2. Pingback: New JavaScript inspections and intentions | WebStorm & PhpStorm Blog

  3. A M-A says:

    So I’m having trouble documenting AMD style modules. As soon as I have a local variable named the same as my API type it won’t enforce the JSDoc documentation.

    e.g.
    require(['MyClass'], function (MyClass) {
    var myClass = new MyClass(); //MyClass is documented elsewhere but not enforced
    });

    Any clues on how to do this?

  4. ksafonov says:

    This is not supported at the moment. May I ask you to submit a ticket at http://youtrack.jetbrains.com/issues/WEB? This way others will see it and you will be notified on our progress at the first hand. Thanks!

  5. Oliver Mannion says:

    Love this feature. I have a question though. How do I document a parameter with multiple types. The following:

    @param {function(Ajax.Response | Document)} okCallback

    generates

    Unresolved variable or type ‘Response | Document)’

    • Konstantin Ulitin says:

      You should add parens wrapping these types, i.e.
      @param {function((Ajax.Response | Document))} okCallback

  6. ST says:

    What about validating CoffeeScript code the same way? Do you have plans to implement it?

Comments are closed.