{"action":"created","issue":{"url":"https://api.github.com/repos/eslint/eslint/issues/4373","labels_url":"https://api.github.com/repos/eslint/eslint/issues/4373/labels{/name}","comments_url":"https://api.github.com/repos/eslint/eslint/issues/4373/comments","events_url":"https://api.github.com/repos/eslint/eslint/issues/4373/events","html_url":"https://github.com/eslint/eslint/issues/4373","id":116024390,"number":4373,"title":"Sequential fixes regression","user":{"login":"adametry","id":2266622,"avatar_url":"https://avatars.githubusercontent.com/u/2266622?v=3","gravatar_id":"","url":"https://api.github.com/users/adametry","html_url":"https://github.com/adametry","followers_url":"https://api.github.com/users/adametry/followers","following_url":"https://api.github.com/users/adametry/following{/other_user}","gists_url":"https://api.github.com/users/adametry/gists{/gist_id}","starred_url":"https://api.github.com/users/adametry/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adametry/subscriptions","organizations_url":"https://api.github.com/users/adametry/orgs","repos_url":"https://api.github.com/users/adametry/repos","events_url":"https://api.github.com/users/adametry/events{/privacy}","received_events_url":"https://api.github.com/users/adametry/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/eslint/eslint/labels/triage","name":"triage","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-11-10T04:37:43Z","updated_at":"2015-11-10T15:19:12Z","closed_at":null,"body":"While checking `gulp-eslint` unit tests against eslint@1.9.0, I found that the \"fix\" option failed to correct the second (earlier in code) of two fixable messages; though, this test would pass prior to 1.9.0. You can find the failing test [here](https://github.com/adametry/gulp-eslint/blob/412098fe32dda7e4adf34c360ec3744e9ddcad25/test/linting.js#L228), or as described below.\r\n\r\n#### CLI-Config\r\n```javascript\r\n{fix: true, rules: {'no-extra-semi': 1, 'no-trailing-spaces': 2}}\r\n```\r\n\r\n#### JS Source\r\n```javascript\r\nvar x = 0;; \r\n```\r\n*Note that there is an extra space after the second comma*\r\n\r\n#### Expected Fixed Output\r\n```javascript\r\nvar x = 0;\r\n```\r\n*Note that the trailing space and second semi-colon have been removed*\r\n\r\n#### Actual Fixed Output:\r\n```javascript\r\nvar x = 0;;\r\n```\r\n*Note that only the trailing space has been removed*\r\n\r\nAfter stepping through the ESLint code, I found that the change #4329 resulted in an off-by-one flaw. Specifically, `fix.range[1]` is an exclusive upper boundary, while `lastFixPos` is an inclusive lower boundary from the previous fix. When the opposing bounds are equal, the two boundaries do not overlap; rather, they are adjacent.\r\n\r\n*eslint v1.9.0 (via gulp-eslint@1.1.0)*\r\n\r\n<bountysource-plugin>\r\n---\r\nWant to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/28115498-sequential-fixes-regression?utm_campaign=plugin&utm_content=tracker%2F282608&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282608&utm_medium=issues&utm_source=github).\r\n</bountysource-plugin>"},"comment":{"url":"https://api.github.com/repos/eslint/eslint/issues/comments/155449100","html_url":"https://github.com/eslint/eslint/issues/4373#issuecomment-155449100","issue_url":"https://api.github.com/repos/eslint/eslint/issues/4373","id":155449100,"user":{"login":"platinumazure","id":284282,"avatar_url":"https://avatars.githubusercontent.com/u/284282?v=3","gravatar_id":"","url":"https://api.github.com/users/platinumazure","html_url":"https://github.com/platinumazure","followers_url":"https://api.github.com/users/platinumazure/followers","following_url":"https://api.github.com/users/platinumazure/following{/other_user}","gists_url":"https://api.github.com/users/platinumazure/gists{/gist_id}","starred_url":"https://api.github.com/users/platinumazure/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/platinumazure/subscriptions","organizations_url":"https://api.github.com/users/platinumazure/orgs","repos_url":"https://api.github.com/users/platinumazure/repos","events_url":"https://api.github.com/users/platinumazure/events{/privacy}","received_events_url":"https://api.github.com/users/platinumazure/received_events","type":"User","site_admin":false},"created_at":"2015-11-10T15:19:11Z","updated_at":"2015-11-10T15:19:11Z","body":"@gyandeeps I looked at the original issue and I think maybe a different\napproach could be made.\n\nThe problem in that case was that, while the same range was used to\nindicate where the fix should be applied, in reality one fix (eqeqeq) had\nto do with the token before the fix location, and the other\n(space-unary-ops) had to do with the token after.\n\nI think the old issue could be fixed by changing eqeqeq's fix function to\n*replace* the text range represented by the double-equal operator with a\ntriple equal. This implies the start range of that fix is earlier, so that\nfix is applied second. Then we could revert the off-by-one change.\n\nWould it be okay if I created a pull request to that effect, so we can see\nif it works?\nOn Nov 10, 2015 9:05 AM, \"Gyandeep Singh\" <notifications@github.com> wrote:\n\n> This is a deliberate change made to the core as previously overlapping\n> fixes was creating issues.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/eslint/eslint/issues/4373#issuecomment-155444863>.\n>\n"}}