Bug: no-warning-comments does not work with multiline comments
See original GitHub issueThere is exact same issue, that marked as resolved, but it seems there is regression?
Previous issue: https://github.com/eslint/eslint/issues/9884
I will copy description from linked issue, except I’ve updated the environment.
I’m going to report using the online demo rather than my own project, so that anyone else can reproduce this bug as well. It happens in the online demo. https://eslint.org/demo
Environment
Node version: 18.2.0 npm version: 8.9.0 Local ESLint version: 8.13.0 Global ESLint version: 8.13.0 Operating System: macOS 12.4
What parser are you using?
What did you do?
Configuration
{
"parserOptions": {
"ecmaVersion": 5,
"sourceType": "script",
"ecmaFeatures": {}
},
"rules": {
"constructor-super": 2,
"no-case-declarations": 2,
"no-class-assign": 2,
"no-compare-neg-zero": 2,
"no-cond-assign": 2,
"no-console": 2,
"no-const-assign": 2,
"no-constant-condition": 2,
"no-control-regex": 2,
"no-debugger": 2,
"no-delete-var": 2,
"no-dupe-args": 2,
"no-dupe-class-members": 2,
"no-dupe-keys": 2,
"no-duplicate-case": 2,
"no-empty-character-class": 2,
"no-empty-pattern": 2,
"no-empty": 2,
"no-ex-assign": 2,
"no-extra-boolean-cast": 2,
"no-extra-semi": 2,
"no-fallthrough": 2,
"no-func-assign": 2,
"no-global-assign": 2,
"no-inner-declarations": 2,
"no-invalid-regexp": 2,
"no-irregular-whitespace": 2,
"no-mixed-spaces-and-tabs": 2,
"no-new-symbol": 2,
"no-obj-calls": 2,
"no-octal": 2,
"no-redeclare": 2,
"no-regex-spaces": 2,
"no-self-assign": 2,
"no-sparse-arrays": 2,
"no-this-before-super": 2,
"no-undef": 2,
"no-unexpected-multiline": 2,
"no-unreachable": 2,
"no-unsafe-finally": 2,
"no-unsafe-negation": 2,
"no-unused-labels": 2,
"no-unused-vars": 2,
"no-useless-escape": 2,
"require-yield": 2,
"use-isnan": 2,
"valid-typeof": 2,
"no-warning-comments": 2
},
"env": {}
}
/**
* todo
*/
/*
* todo
*/
// todo
var foo = bar;
Run it in the online demo.
What did you expect to happen?
The sections
/*
* todo
*/
and
/**
* todo
*/
should be flagged for no-warning-comments
.
What actually happened?
Only
// todo
is flagged for no-warning-comments
.
Participation
- I am willing to submit a pull request for this issue.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:17 (15 by maintainers)
Top Results From Across the Web
no-warning-comments - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >Multi line comment Not working | Codecademy
I receive the following error message: Oops, try again. It looks like you didn't include =begin. Make sure there's no space between the...
Read more >Enable ESLint rule "no-warning-comments" on devtools code
Yeah I don't know if it's possible with eslint. It would at least need to span multiple one line comments (and/or a multiline...
Read more >Why doesn't Python have multiline comments? - Stack Overflow
I have worked in a lot of fields where if your code contains commented out code then your code is rejected and you...
Read more >Multiline comments don't work with documentation tags in C++.
You can see details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017#faq . Please comment below if you have additional data ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I agree that this should be fixed by adding a new option.
The option could accept an array of characters to (optionally) skip at the start of the comment when checking whether it starts with disallowed terms? Similar to https://github.com/eslint/eslint/issues/16103#issuecomment-1180304234:
These characters would be added to the
prefix
part of the pattern (in the above example,prefix
would be"^[\\s*]*"
) so that they can also appear at the start of configuredterms
.Hi @Reeywhaar, thanks for the issue!
We were just discussing this in https://github.com/eslint/eslint/pull/16090, and it doesn’t seem that the original issue https://github.com/eslint/eslint/issues/9884 was actually resolved at the time.
I agree that this rule should treat these two comments as starting with ‘todo’ despite the extra
*
characters. But since the original issue was closed a long time ago, I would like more opinions from the team, especially because this change can produce more warnings.