103

Let's say you have something like the following:

var someFunc = function() {
    // do something here with arguments
}

How would you correctly document that this function can take any number of arguments in JSDoc? This is my best guess, but I'm not sure it's correct.

/**
 * @param {Mixed} [...] Unlimited amount of optional parameters
 */
var someFunc = function() {
    // do something here with arguments
}

Related to: php - How to doc a variable number of parameters

Community
  • 1
  • 1
kflorence
  • 2,187
  • 2
  • 16
  • 15

4 Answers4

149

The JSDoc specs and Google's Closure Compiler do it this way:

@param {...number} var_args

Where "number" is the type of arguments expected.

The complete usage of this, then, would look like the following:

/**
* @param {...*} var_args
*/
function lookMaImVariadic(var_args) {
    // Utilize the `arguments` object here, not `var_args`.
}

Note the comment about utilizing arguments (or some offset of arguments) to access your additional arguments. var_args it just used to signal to your IDE that the argument does indeed exist.

Rest parameters in ES6 can take the real parameter one step further to encompass provided values (so no more use of arguments is necessary):

/**
* @param {...*} var_args
*/
function lookMaImES6Variadic(...var_args) {
    // Utilize the `var_args` array here, not `arguments`.
}
Patrick Hund
  • 19,163
  • 11
  • 66
  • 95
Dawson Toth
  • 5,580
  • 2
  • 22
  • 37
  • This is probably as close to an answer as we can get :) – kflorence Feb 04 '11 at 00:46
  • 2
    Also worth noting, WebStorm's internal JSDoc files (DHTML.js, etc) use this same syntax. Maybe it's the de-facto standard. – Scott Rippey Jul 18 '12 at 20:52
  • 2
    it's also described quite well here: http://usejsdoc.org/tags-param.html (section 'Allows a parameter to be repeated') – Francois Jul 25 '14 at 21:23
  • This answer should be edited to integrate Adrian Holovaty's answer: there *needs* to be an actual variable called `var_args` or whatever you want to call in as the sole parameter. Sad hack. – Oli Oct 13 '15 at 01:23
  • 1
    With the addition of [rest parameters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters) in ES6, this makes a lot more sense. `/** @param {...Function} tasks The tasks. */ function waterfallTasks(...tasks) {` Rest parameters always have a functional presence in the parameters. – Shibumi Nov 11 '16 at 16:55
  • What if my function has single concrete param followed by spread one? I mean `@param {SomeType} x @param {...SomeOtherType} y` confuses Webstorm. He recognises x as `SomeOtherType`. Function signature looks like this: `function foo(x, ...y)` – Kamil Latosinski Dec 06 '17 at 10:03
  • The @ param {...*} notation doesn't work with closure compiler, though @ param {...} does. Apparently @ type {...*} works though. – Alex Li Aug 10 '20 at 21:54
32

How to do this is now described in the JSDoc documentation, and it uses an ellipsis like the Closure docs do.

@param {...<type>} <argName> <Argument description>

You need to supply a type to go after the ellipsis, but you can use a * to describe accepting anything, or use the | to separate multiple acceptable types. In the generated documentation JSDoc will describe this argument as repeatable, in the same way it describes optional arguments as optional.

In my testing there was no need to have an argument in the actual javascript function definition, so your actual code can just have empty parentheses, i.e. function whatever() { ... }.

Single type:

@param {...number} terms Terms to multiply together

Any type (in the example below, the square brackets mean items will get tagged as both optional and repeatable):

@param {...*} [items] - zero or more items to log.

Multiple types need parentheses around the type list, with the ellipsis before the opening paren:

@param {...(Person|string)} attendees - Meeting attendees, listed as either 
                                        String names or {@link Person} objects
Daniel Baird
  • 2,239
  • 1
  • 18
  • 24
  • 1
    And what about object used as key-value pairs ?. Currently I use: `@param {{...(key: value)}} [config] - specific configs for this transfer` but was wondering if this is correct ? – Max Apr 24 '15 at 06:36
  • @Max I can't tell from the docs if that's the official right way to do it, but it looks like it should work as expected. So if it generates output you are okay with, I'd use it :) – Daniel Baird May 08 '15 at 02:22
11

I futzed with this for quite some time. Here's how to do it with Google Closure Compiler:

/**
* @param {...*} var_args
*/
function my_function(var_args) {
    // code that accesses the magic 'arguments' variable...
}

The key is to give your function a var_args parameter (or whatever you call it in your @param statement) even though the function doesn't actually use that parameter.

Adrian Holovaty
  • 2,249
  • 2
  • 16
  • 17
11

From the JSDoc users group:

There isn't any official way, but one possible solution is this:

/**
 * @param [...] Zero or more child nodes. If zero then ... otherwise ....
 */

The square brackets indicate an optional parameter, and the ... would (to me) indicate "some arbitrary number."

Another possibility is this...

/**
 * @param [arguments] The child nodes.
 */

Either way should communicate what you mean.

It's a bit dated, though (2007), but I'm not aware of anything more current.

If you need to document the param type as 'mixed', use {*}, as in @param {*} [arguments].

hashchange
  • 7,029
  • 1
  • 45
  • 41
  • 7
    I don't mind having my answer downvoted, but I do expect a comment explaining why you did it (whoever you are). If you think it is wrong, let me - and all of us - know why. – hashchange Jul 24 '13 at 10:29
  • 2
    My IDE of choice (WebStorm 8.0.1) supports syntax #2 `@param [arguments]` (or `@param {*} [arguments]` for that matter) as well as the syntax established by Google Closure compiler (mentioned in another answer). `@param [...]` is not supported. – mistaecko Apr 12 '14 at 09:44
  • @mistaecko but only with named parameters correct? That's what I'm not using, so this isn't a acceptable answer for me... – Sebastian Dec 12 '14 at 10:18