question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

New multiline-comment-style fails for jsdoc on export default of objects

See original GitHub issue

Tell us about your environment

  • ESLint Version: 4.9.0
  • Node Version: 8.6.0
  • npm Version: 5.3.0

What parser (default, Babel-ESLint, etc.) are you using? default

What did you expect to happen? I configured th new rule multiline-comment-style as an error, using “separate-lines”, in yaml, like this:

    - multiline-comment-style: [2, separate-lines]

I’d expect no error on these jsdoc blocks:

import {Model} from 'backbone';

/**
 * Some docs
 *
 * @class SomeModel
 */
export default Model.extend({
    defaults: {
        'some': 'fields'
    }
});

I tried this, but this also fails in the same way:

import {Model} from 'backbone';

/**
 * Some docs
 *
 * @class SomeModel
 */
const SomeModel = Model.extend({
    defaults: {
        'some': 'fields'
    }
});

export default SomeModel;

What actually happened? Please include the actual, raw output from ESLint.

Got an error on the line containing the comment, saying “Expected multiple line comments instead of a block comment.”.

It does not give the same error for functions defined like this:

/**
 * My function
 *
 * @function myFunc
 */
const myFunc = function() {

}

Or this:

/**
 * My function
 *
 * @function myFunc
 */
export default function() {

}

The way of defining models as described above is a pretty standard way of defining backbone models, so it would be great if we were able to support this style as well.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
not-an-aardvarkcommented, Oct 19, 2017

The rule is supposed to ignore all JSDoc comments when in separate-lines (or bare-block) mode, but it’s possible there is a bug in that logic.

0reactions
jaapzcommented, Oct 30, 2017

Very sorry for wasting all you guy’s times, bug was in our own code as the jsdoc was aligned wrong:

/**
* There was no space before this line, while it should have one
*/
export default Model.extend({
 ...
});

Eslint sees this (i think correctly) as a block comment.

Read more comments on GitHub >

github_iconTop Results From Across the Web

JSDoc broken on `exports.default` in VSCode? - Stack Overflow
JSDocs information is shown for named exports, but not for default exports with the commonJS export method. Problem: No info popup on exports....
Read more >
eslint-config-ash-nazg - npm
An expansion and tweaking of the "standard" config style for ESLint. Latest version: 34.6.0, last published: 13 days ago.
Read more >
Disallow specified names in exports (no-restricted-exports)
Rule Details. This rule disallows specified names from being used as exported names. Options. By default, this rule doesn't disallow any names.
Read more >
Rules - ESLint - Pluggable JavaScript Linter
Disallow `new` operators with the `Symbol` object. Categories: ... Enforce default clauses in switch statements to be last ... multiline-comment-style.
Read more >
eslintrc.json - hyperledger-labs/blockchain-explorer
"multiline-comment-style": ["error"],. "no-extra-parens": ["error"], ... "import/prefer-default-export": ["off"], ... "import/no-named-as-default": ["off"],.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found