Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Add support to decorators #455

Closed
alejandroclaro opened this issue Dec 23, 2019 · 5 comments
Closed

Feature request: Add support to decorators #455

alejandroclaro opened this issue Dec 23, 2019 · 5 comments

Comments

@alejandroclaro
Copy link

alejandroclaro commented Dec 23, 2019

I'm trying to use eslint-plugin-jsdoc in a project where decorators are been used and needed in general. However, the rule 'jsdoc/require-jsdoc' warns about missing documentation when the decorator is placed between the comment and the entity:

/**
 * Class documentation
 */
 @AnyDecorator({
  'property': 'value'
})
export default class Foo {
 // ....
}

The alternative is to move the decorator before the comment. But it does not look good and it's error-prone.

 @AnyDecorator({
  'property': 'value'
})
/**
 * Class documentation
 */
export default class Foo {
 // ....
}

It will be good that this feature is supported, even with decorators in stage 2. It has become a fairly common feature in many libraries lately. It is quite annoying to work with the alternative option in projects where documentation is a mandatory requirement and such a valuable tool as this plugin helps to detect violations.

brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Dec 23, 2019
…block and context object; fixes gajus#455

This is incomplete as it needs to support parenthesized decorators
@brettz9
Copy link
Collaborator

brettz9 commented Dec 23, 2019

If you want to dig into this, you can take a look at https://github.com/brettz9/eslint-plugin-jsdoc/tree/require-jsdoc-decorators . It was trivial to allow a bare @decorator, but with parenthesized tokens prior, it would require some parentheses-and-type matching. If you log tokenBefore, you can introspect on the tokens.

This is not a priority for me to complete this, but it was easy enough to demo the kind of approach that would be needed.

For testing, I recommend running npm run test-index --rule=require-jsdoc --valid=-1. This will let you just run the last "valid" rule in the require-jsdoc test file, and you can do logging to see what is going on.

brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Dec 27, 2019
…omment block and context object; fixes part of gajus#455

This does not yet support intervening parenthesized decorators
@brettz9
Copy link
Collaborator

brettz9 commented Dec 27, 2019

I've since merged my branch to handle intervening simple decorators, so that can now be found in master (added with 641479b).

@brettz9
Copy link
Collaborator

brettz9 commented Jun 18, 2020

The decorator in the example has been working now as intended, so closing. Feel free to reopen if we are not properly skipping over some forms of decorators to expect or place the comment block above the decorator.

@brettz9 brettz9 closed this as completed Jun 18, 2020
@boy51
Copy link

boy51 commented Sep 8, 2020

Hi, I'm still having issues in a NestJS project where decorators are used extensively. I hope this is the right place to post as I'm not sure if it's a bug or an issue in my config.

Overall the rule is working but when it comes to class declarations it doesn't seem to properly skip over decorators.

/**
 * This jsdoc isn't recognized
*/
@Controller('user-settings')
@UseGuards(AuthGuard())
export class UserSettingsController { // <------- This still gives me a require-jsdoc warning
  /**
   * This jsdoc is recognized even with decorators in between.
   * @param {UbwUser} user
   * @return {Promise<UserSettings>}
   */
  @Get()
  async getUserSettings(@GetUser() user: UbwUser): Promise<UserSettings> { // <----- This is ok
    const settings = await this.userSettingsService.getUserSettings(user.id)
    delete settings.userId

    return settings
  }
}

The problem here is that, if the doc is placed above class declaration and below decorators, VSCode doesn't seem to recognize the doc, and if the doc is placed above decorators of class declaration, eslint doesn't recognize it.

I haven't experienced this issue anywhere else. Only with class declarations.

Here's my eslint config. I'm using eslint-config-google on top of eslint-recommended.

module.exports = {
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: 'tsconfig.json',
    sourceType: 'module',
  },
  plugins: ['@typescript-eslint/eslint-plugin'],
  extends: [
    'plugin:@typescript-eslint/eslint-recommended',
    'plugin:@typescript-eslint/recommended',
    'google',
    'prettier',
    'prettier/@typescript-eslint',
  ],
  root: true,
  env: {
    node: true,
    jest: true,
  },
  rules: {
    '@typescript-eslint/explicit-function-return-type': 'off',
    '@typescript-eslint/no-explicit-any': 'off',
    'new-cap': 'off',
    'require-jsdoc': [
      'warn',
      {
        require: {
          FunctionDeclaration: true,
          MethodDefinition: true,
          ClassDeclaration: true,
        },
      },
    ],
    semi: ['error', 'never'],
  },
}

@brettz9
Copy link
Collaborator

brettz9 commented Sep 9, 2020

Please file a new issue with the requested info, and indicate the version of eslint-plugin-jsdoc you are using. I'm not seeing an issue against the current version, though I don't know if the tsconfig could have anything to do with it. Please also try to reduce your config to the minimum that finds the problem, and if it needs tsconfig, please supply your tsconfig in the issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants