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
require-jsdoc
with option config produces "TypeError: Cannot read property 'type' of undefined"
#378
require-jsdoc
with option config produces "TypeError: Cannot read property 'type' of undefined"
#378
Comments
While this looks like a dupe of #376 , unlike that one, I was able to confirm this issue in our testing environment: {
code: `
const foo = {...{}};
function bar() {}
`,
options: [
{
exemptEmptyFunctions: false,
publicOnly: true,
require: {
ArrowFunctionExpression: true,
ClassDeclaration: true,
ClassExpression: true,
FunctionDeclaration: true,
FunctionExpression: false,
MethodDefinition: true,
},
},
],
parser: require.resolve('babel-eslint'),
parserOptions: {
ecmaFeatures: {
jsx: true,
},
ecmaVersion: 2017,
sourceType: 'module',
},
} |
@Extersky : Would you be able to take a look? |
This bug is blocking redux-orm/redux-orm#296 (failing build):
The parsed code can be found at https://github.com/redux-orm/redux-orm/blob/db1f15d22c9890d236e57a53bb4afa2d5ce40dfc/src/selectors/FieldSelectorSpec.js. |
@Extersky : Any chance for looking at this? |
It turns out our issue seems to have been a different one (eslint/eslint#12335) and has been fixed by the ESLint v6.5.1 release. Thanks anyways 🙂 |
I ran into this too, confirmed fixed in Eslint v6.5.1 |
With ten thumbs up on the issue, if folks are antsy for a fix, there's always funding on Issuehunt to potentially expedite things. |
require-jsdoc
with option config produces "TypeError: Cannot read property 'type' of undefined"
🎉 This issue has been resolved in version 15.12.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
While my fix won't allow catching things like const foo = {
method2 () {
}
};
module.exports = {
/**
*
*/
method1 () {
},
...foo
}; ...it should at least avoid the error, and for those using |
This rule still breaks for me with 20.0.0 when I have publicOnly option enabled with typescript files:
When I remove the publicOnly option, it works. |
I am not getting an error when adding a test locally. But from the looks of the stack trace, Do you have an example file, preferably a minimal one that triggers the error (and there could be errors in more than one place, as we don't have any tests for I could provide a guard that avoids the specific exception, but I'd like to know what other cases there may be where there is a property but no |
@olee : I see there is a difference in the AST with typescript-parser and the default parser. Fixed in v20.0.1 . If there are other issues remaining, please file a new issue with a reproducible test case. Thanks. |
First filed on
eslint
, narrowed down to (probably)eslint-plugin-jsdoc
.Tell us about your environment
5.16.0
10.16.0
6.9.0
What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint@10.0.1
Please show your full configuration:
https://gist.github.com/ericsoco/4fcaacaed0bb083fd72688fee5ee381f
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
Minimal repro seems to include spreading an object in a const definition, followed by a function declaration or expression.
What did you expect to happen?
Lints as usual
What actually happened? Please include the actual, raw output from ESLint.
Workaround is to add a JSDoc comment to the function declaration:
Don't know for a fact the error is thrown from
eslint-plugin-jsdoc
, but this workaround makes it seem likely.The text was updated successfully, but these errors were encountered: