Create a eslint formatter that can filter out known errors in a file

RESOLVED WONTFIX

Status

Firefox OS
Gaia::Build
RESOLVED WONTFIX
2 years ago
3 months ago

People

(Reporter: julienw, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
When we'll transition from jshint to eslint, we'll want to enable new checks. Of course these new checks won't pass on all gaia, so we need a selective formatter to filter out known errors in a file.
Created attachment 8710405 [details] [review]
[gaia] julienw:1241464-eslint-proper-xfail > mozilla-b2g:master
(Reporter)

Comment 2

2 years ago
Comment on attachment 8710405 [details] [review]
[gaia] julienw:1241464-eslint-proper-xfail > mozilla-b2g:master

Hey Freddy,

because you've set up eslint, I'd like your opinion on such formatter. 

When we have a working formatter and configuration, I'd like to enable more checks using eslint (with [1] as base that I did for another project, but thinking to gaia :)).

[1] https://github.com/julienw/wobble/blob/master/.eslintrc.json
Attachment #8710405 - Flags: feedback?(fbraun)
I'm generally fine with the approach. I'm just afraid that whatever eslint related we do, we'll just grow the list instead of shrinking it.
Also, I'm regularly monitoring the commit history of the current xfail list to stay on top of potential security violations, adding more stuff to it makes this harder too.

I wonder if we could somehow get separated faliure lists. Probably not without running eslint multiple times, which is meh.
(Reporter)

Comment 4

2 years ago
(In reply to Frederik Braun [:freddyb] from comment #3)
> I'm generally fine with the approach. I'm just afraid that whatever eslint
> related we do, we'll just grow the list instead of shrinking it.

We actually did this when we switched to jshint and it eventually worked (we don't have a xfail.list for jshint anymore). Also a lot of the stylistic changes are fixable using the option "--fix".

This is IMO the only solution if we want to eventually use stricter rules. Given the size of the codebase we can't change all at once and rather let the app developers do their own fixes at their own speed. Or not. Or add their own .eslintrc to add more or remove some rules. Their choice :)

> Also, I'm regularly monitoring the commit history of the current xfail list
> to stay on top of potential security violations, adding more stuff to it
> makes this harder too.
> 
> I wonder if we could somehow get separated faliure lists. Probably not
> without running eslint multiple times, which is meh.

The list format I used is very easily generate by "eslint -f unix > xfail.list". That's why it's good to have it in one list only.

I think you could still monitor using a git command like "git log -Sno-unsafe-innerhtml build/eslint/xfail.list". This should give you only the changes that changed a line containing this test.

Would still work for you ?
(Reporter)

Comment 5

2 years ago
> Would still work for you ?
I meant: Would this work for you ?
Comment on attachment 8710405 [details] [review]
[gaia] julienw:1241464-eslint-proper-xfail > mozilla-b2g:master

Yeah, you're right. I'll just grep the git log :)
Attachment #8710405 - Flags: feedback?(fbraun) → feedback+
(Reporter)

Comment 7

2 years ago
So using babel-eslint makes the array comprehension syntax work. But I'm not sure we should use it actually, because array comprehensions is a non-standard feature and the current syntax will likely be deprecated and remove from gecko.

See bug 1232618, bug 1240454 and especially bug 1220564.

How man, I even think it's been removed already !! bug 1220564 comment 23 !!

Comment 8

3 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.