Eslint-plugin-jsdoc: "require-returns" requires useless return statements for return type "undefined"

Created on 7 Jan 2019  路  8Comments  路  Source: gajus/eslint-plugin-jsdoc

Subject says it. If the return type is undefined I don't need a return statement in the code.

This plugin should concern itself with JSDoc — not with the code style! The return type when there is no return statement is undefined, so describing such a function as having @returns {undefined} is 100% correct. I should not get

Present JSDoc @returns declaration but not available return expression in function  jsdoc/require-returns
bug enhancement help wanted released

Most helpful comment

It's no PR, but might be helpful. This is the change I made to work around this bug and get my code validating:

https://github.com/gajus/eslint-plugin-jsdoc/blob/master/src/rules/requireReturns.js

// replace
if (JSON.stringify(jsdocTags) !== '[]' && sourcecode.indexOf('return') < 1) {
// with
if (JSON.stringify(jsdocTags) !== '[]' && jsdocTags.findIndex(v => ['undefined', 'void'].indexOf(v.type) !== -1) === -1 && sourcecode.indexOf('return') < 1) {

Lots of the core ESLint rules seem to have a configurable options object to enable/disable parts of a rule, As this rule has 2 report() cases maybe it would be logical to allow them to be enabled separately?

All 8 comments

PR is welcome.

Sure, always. And so are big reports, and here is one.

According to ESLint, @returns {void} should be valid.

According to Google Closure Compiler, omitting it completely or @returns {undefined] should be valid. The following should all be tests that satisfy these requirements.

valid: [
    { // pass
      code: `
          /**
           * @returns {Object}
           */
          function quux () {

            return {a: foo};
          }
      `
    },
    { // fail
      code: `
          /**
           * @returns {Object}
           */
          const quux = () => ({a: foo});
      `
    },
    { // pass
      code: `
          /**
           * @returns {Object}
           */
          const quux = () => {
            return {a: foo}
          };
      `
    },
    { // fail
      code: `
          /**
           * @returns {void}
           */
          function quux () {
          }
      `
    },
    { // fail
      code: `
          /**
           * @returns {void}
           */
          const quux = () => {

          }
      `
    },
    { // fail
      code: `
          /**
           * @returns {undefined}
           */
          function quux () {
          }
      `
    },
    { // fail
      code: `
          /**
           * @returns {undefined}
           */
          const quux = () => {

          }
      `
    },
    { // pass
      code: `
          /**
           *
           */
          function quux () {
          }
      `
    },
    { // pass
      code: `
          /**
           *
           */
          const quux = () => {

          }
      `
    }
  ]

Pass/Fail comments are as of v3.15.1.

It's no PR, but might be helpful. This is the change I made to work around this bug and get my code validating:

https://github.com/gajus/eslint-plugin-jsdoc/blob/master/src/rules/requireReturns.js

// replace
if (JSON.stringify(jsdocTags) !== '[]' && sourcecode.indexOf('return') < 1) {
// with
if (JSON.stringify(jsdocTags) !== '[]' && jsdocTags.findIndex(v => ['undefined', 'void'].indexOf(v.type) !== -1) === -1 && sourcecode.indexOf('return') < 1) {

Lots of the core ESLint rules seem to have a configurable options object to enable/disable parts of a rule, As this rule has 2 report() cases maybe it would be logical to allow them to be enabled separately?

Lots of the core ESLint rules seem to have a configurable options object to enable/disable parts of a rule, As this rule has 2 report() cases maybe it would be logical to allow them to be enabled separately?

Makes sense.

Hi,
Sorry for this bug. I fix this in a pull request.
I use @ChrisHSandN patch (thanks, imho is ok) and split this rule in two rules.

I would hope that this behavior could made optional because I personally always want returns documented so as to flag there has been no omission in consideration of return values for documentation.

:tada: This issue has been resolved in version 4.8.2 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michaelfarrell76 picture michaelfarrell76  路  4Comments

kirkstrobeck picture kirkstrobeck  路  4Comments

hipstersmoothie picture hipstersmoothie  路  3Comments

lgaticaq picture lgaticaq  路  6Comments

zhaparoff picture zhaparoff  路  3Comments