Bugzilla – Full Text Bug Listing
| Summary: | [eslint] Follow up on rules consumed from ESLint | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Curtis Windatt <curtis.windatt.public> |
| Component: | JS Tools | Assignee: | Curtis Windatt <curtis.windatt.public> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Olivier_Thomann |
| Version: | 11.0 | ||
| Target Milestone: | 11.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 467903 | ||
| Bug Blocks: | |||
3) Sure. I put it as error to get rid of parens what are not needed. 4) I can take a look at where the error is reported. This could be a separate bug report. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=f727a90ba7ef3f2ab3afb52973bf36dde9e2d045 Fixes (1) and (2) http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=7a3b180cfc3b9e1aab4bed85c17eece624aaa11a Changes (3) to warning 4) This is really minor and looking at the rule source the behaviour makes sense. It simply reports the in operator node as the context, which includes the whitespace and the LHS (unary operation). Closing this as FIXED. |
List of minor issues with the consumed rules. 1) Typo in no-control-regex description 2) Some tests use the same describe name 3) Should no-extra-parens rule be warning by default, not error? If someone is using parentheses to separate logic, even if order of operations would work without parens, that doesn't feel like an error status is warranted. 4) no-negated-in-lhs rule annotates the whitespace beside the in if (!a in foo){} The annotation includes the trailing whitespace after 'in'.