So a lot of the work done so far has been removing all this non-standard stuff so that ESLint can pass with only a very small set of style rules defined. Soon we’ll start increasing the rules we check in browser and toolkit.
How do I lint?
From the command line this is simple. Make sure and run
./mach eslint --setup to install eslint and some related packages then just
./mach eslint <directory or file> to lint a specific area. You can also lint the entire tree. For now you may need to periodically run setup again as we add new dependencies, at some point we may make mach automatically detect that you need to re-run it.
You can also add ESLint support to many code editors and as of today you can add ESLint support into hg!
- Linting can be used to enforce the sorts of style rules that keep our code consistent. Imagine no more nit comments in code review forcing you to update your patch. You can fix all those before submitting and reviewers don’t have to waste time pointing them out.
- Linting can catch real bugs. When we turned on one of the basic rules we found a problem in shipping code.
- With only standard JS code to deal with we open the possibility of using advanced like AST transforms for refactoring (e.g. recast). This could be very useful for switching from Cu.import to ES6 modules.
- ESLint in particular allows us to write custom rules for doing clever things like handling head.js imports for tests.
Where are we?
There’s a full list of everything that has been done so far in the dependencies of the ESLint metabug but some highlights:
- Removed #include preprocessing from browser.js moving all included scripts to global-scripts.inc
- Added an ESLint plugin to allow linting the JS parts of XBL bindings
- Fixed basic JS parsing issues in lots of b2g, browser and toolkit code
- Created a hg extension that will warn you when committing code that fails ESLint
- Turned on some basic linting rules
- Mozreview is close to being able to lint your code and give review comments where things fail
- Work is almost complete on a linting test that will turn orange on the tree when code fails to lint
I’m grateful to all those that have helped get things moving here but there is still more work to do. If you’re interested there’s really two ways you can help. We need to lint more files and we need to turn on more lint rules.
We also need to turn on more rules. We’ve got a rough list of the rules we want to turn on in browser and toolkit but as you might guess they aren’t on because they fail right now. Fixing up our JS to work with them is simple work but much appreciated. In some cases ESLint can also do the work for you!
How would you feel about using typescript, that might help taking the check a bit further and ease maintenance and refactoring?
Comments are closed.