@param name not recognized if on the next line after the parameter type

[danfuzz]

Expected behavior

If a @param ... definition is split across multiple lines, such that there is a line break after the parameter type, the first word on the next line should be recognized as the parameter name.

Actual behavior

In this situation, the parameter name isn't recognized as such, thereby eliciting errors along these lines:

  1:1  warning  Missing JSDoc @param "foo" declaration        jsdoc/require-param
  2:1  warning  Expected @param names to be "foo". Got ""     jsdoc/check-param-names
  2:1  warning  There must be an identifier after @param tag  jsdoc/require-param-name

ESLint Config

import js from '@eslint/js';
import jsdocPlugin from 'eslint-plugin-jsdoc';
import globals from 'globals';

export default [
  js.configs.recommended,
  jsdocPlugin.configs['flat/recommended'],
  {
    languageOptions: {
      ecmaVersion: 2024,
      globals: globals.node
    },
    plugins: {
      'jsdoc': jsdocPlugin,
    },
    settings: {
      jsdoc: {
        mode: 'jsdoc'
      }
    }
  },
];

ESLint sample

/**
 * @param {string}
 *   foo The foo.
 */
export function x(foo) {
  console.log(foo);
}

As context, I've run into this when I have a @param with a type exactly long enough to warrant wrapping the parameter name onto the next line.

In case it's handy, here's a tarball of the example. You can unpack it and then run ./demo:

bug-report.tar.gz

Environment

• Node version: 23.6.0
• ESLint version 9.18.0
• eslint-plugin-jsdoc version: 50.6.1

[brettz9]

Unfortunately, the parser on which we rely, comment-parser, though it does allow for multi-line types and descriptions, does not allow for names in that position.

While there are other edge cases where it would be beneficial to switch parsers, it would be a lot of work, and I don't have the bandwidth to work on this.

Perhaps a PR to comment-parser to add support would be the path of least resistance if someone had the inclination.