Function straight after "require" adds "ccccccccccccccccc" before require argument when using eslint to format with this plugin on vscode

[talkingnews]

Problem

When using this great plugin, formatting the document using eslint in visual code messes up, but ONLY when I declare a function after a require. So....

const a = require('./a.json')

function tester () {
  console.log(a)
}

Outputs this when formatting using eslint:

const a = require/**
ccccccccccccccccc *
ccccccccccccccccc */
('./a.json')

function tester () {
  console.log(a)
}

But if I add const test = true between require and function, it's OK.

So

const a = require('./a.json')

const test = true

function tester () {
  console.log(a)
}

formats as

const a = require('./a.json')

const test = true

/**
 *
 */
function tester () {
  console.log(a)
}

 tester()

ESLint Config

module.exports = {
  env: {
    browser: false,
    commonjs: true,
    es2021: true
  },
  plugins: [
    'jsdoc'
  ],
  extends: [
    'standard', 'plugin:you-dont-need-lodash-underscore/compatible', 'plugin:you-dont-need-momentjs/recommended', 'plugin:jsdoc/recommended'
  ],
  parserOptions: {
    ecmaVersion: 2021
  },
  rules: {
    camelcase: 'off'
  }
}

Environment

• Node version: 14.5.5
• ESLint version 7.20.0
• eslint-plugin-jsdoc version: 32.0.2

VSCODE
Version: 1.53.2 (user setup)
Commit: 622cb03f7e070a9670c94bae1a45d78d7181fbd4
Date: 2021-02-11T11:48:04.245Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 10.0.19042

[brettz9]

Yeah, I believe this was fixed with the code in v31.3.1. I believe if you were to test against that version, your require example, will avoid setting a comment above parentheses, detecting that there is no decorator at-sign at the other end. However, I reverted this fix in v31.3.2 because the fix can degrade performance by about 25% for a large project.

The problem was that in skipping past potential decorators (so as to put jsdoc blocks above them), when projects do not use semi-colons (whose presence informs us that we don't need to keep looking for a decorator), our approach in v31.3.1 can end up going back rather far, as can be a problem for performance in large files.

I expect it could be much faster to iterate through the parent chain on the AST to look for a decorator rather than iterating through tokens. (If not, we might need to add an option to opt into decorator checks and disable it by default, but I hope/expect that won't be necessary.)

[gajus]

🎉 This issue has been resolved in version 32.0.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀