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

// eslint-disable ... comments are not ignored anymore by line-comment-position rule #11415

Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion bug ESLint is working incorrectly rule Relates to ESLint's core rules

Comments

@chrisguttandin
Copy link

Tell us about your environment

  • ESLint Version: 5.14.1
  • Node Version: 11.10.0
  • npm Version: 6.8.0

What parser (default, Babel-ESLint, etc.) are you using? default (parserOptions: { ecmaVersion: '2019', sourceType: 'module' })

Please show your full configuration:

Configuration
{
    "env": {
        "es6": true
    },
    "parserOptions": {
        "ecmaVersion": "2019",
        "sourceType": "module"
    },
    "rules": {
        "no-bitwise": "error",
        "line-comment-position": [ "error", { "position": "above" } ]
    }
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

When linting a file which uses in-line comments to disable a certain rule for only one line I get an error with the configuration above in eslint@5.14.x

const x = 20;

console.log(x >> 5); // eslint-disable-line no-bitwise
eslint -c config.json script.js 

What did you expect to happen?
With previous versions of eslint nothing happens. // eslint-... comments where ignored by the line-comment-position rule.

What actually happened? Please include the actual, raw output from ESLint.
I get an error "3:22 error Expected comment to be above code line-comment-position".

Are you willing to submit a pull request to fix this bug?
Generally yes, but I have no idea where to start.

@chrisguttandin chrisguttandin added bug ESLint is working incorrectly triage An ESLint team member will look at this issue soon labels Feb 19, 2019
@platinumazure
Copy link
Member

Hi @chrisguttandin, thanks for the issue. This does seem like a bug.

By any chance, do you know if this was working in 5.13.x?

@platinumazure platinumazure added rule Relates to ESLint's core rules evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels Feb 19, 2019
@chrisguttandin
Copy link
Author

Hi @platinumazure, thanks for the quick response. I can confirm, that it was working with version 5.13.x.

@not-an-aardvark not-an-aardvark added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Feb 21, 2019
@not-an-aardvark
Copy link
Member

I can reproduce this issue. Based on git bisect, it was caused by 550de1e.

@not-an-aardvark not-an-aardvark self-assigned this Feb 21, 2019
not-an-aardvark added a commit that referenced this issue Feb 21, 2019
Ajv ignores the `default` property in JSON schemas when it appears inside `oneOf`, `anyOf`, or `not`. This commit removes ignored `default` properties and fixes a few bugs in rules that were incorrectly assuming the `default` properties would get processed.
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Aug 25, 2019
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Aug 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.