Sort out the readability/jsdomparser eslint situation

NEW
Unassigned

Status

()

Toolkit
Reader Mode
P2
normal
a year ago
8 months ago

People

(Reporter: Gijs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
m-c is not the canonical repository for readability, which both android and desktop and iOS use for "reader mode" support. Instead, the code lives in github ( https://github.com/mozilla/readability ).

We've tried to add some eslint support to that code, and there's an .eslintrc.js file in the repo. We validate with that file using travis.

On m-c, eslint is disabled (with .eslintignore) for the two files we normally import directly from that repo (JSDOMParser.js, Readability.js).

Taking out that restriction makes eslint fail because rules are enabled in other eslintrc files that are not in the .eslintrc.js that is in the github repo (and that we imported into the directory now on autoland in bug 1177619.

Of course, we could fix the (now small) list of failures and remove the exception... but this seems likely to reoccur in future.

What's the best way of making sure the github-to-m-c migrations go well here, and that we use as strict an eslint as possible in both github and on m-c, for these files ?

Mark, seems you've been driving some of the eslint effort of late, do you have thoughts, maybe also inspired by how Hello dealt with this?
Flags: needinfo?(standard8)
For Hello, we didn't run eslint in m-c. Most of our code was pre-generated (as it was jsx based) and came off release tags in the github repo, hence it wasn't really worth trying to run eslint in m-c. We also kept an eye on m-c and made sure to backport any necessary changes.

My only other thoughts at the moment are to:

- create a sub-directory for the imported files and import the .eslintrc.js into there as well (or just ignore the sub-directory)
- list all of eslint rules in the github repo .eslintrc and explicitly turn them all on or off
- somehow keep the github repo version up to date with the toolkit/.eslintrc version

All of these will probably need some level of management over time, but they're the only real options I can think of at the moment.
Flags: needinfo?(standard8)
FYI, I'm also soon going to be working on bug 1347645 which will make it easier to use eslint-plugin-mozilla from outside gecko, which will hopefully make it easier to keep outside repositories in sync with m-c.
(Reporter)

Updated

8 months ago
Priority: -- → P2
See Also: → bug 1378693
You need to log in before you can comment on or make changes to this bug.