What’s next for ESLint on Firefox Source Code?

History

Around 2015 a couple of projects had started using ESLint in mozilla-central. In the last quarter of 2015, there was a big push to enable ESLint for browser/ and toolkit/ – the two main directories containing the javascript source behind Firefox.

Since then, we have come a long way. We have commands and hooks for developers to use, checks during the review phase, and automatic tests that run against our review tools and our continuous integration branches. Not only that, but we’ve also expanded our coverage to more directories, and expanded the amount of rules that are enabled.

As we’ve done this work, we’ve caught lots of bugs in the code or in our tests (there’s much more than just those links). Some of those have been small, some have been user facing issues. There are also now the countless potential bugs that we don’t get to see where ESLint catches issues for us before they even hit the core source trees. All this helps to save developer time and leaves more for fixing bugs and implementing new features.

Where to next?

There are several things high on the list that we should have as the next, future goals:

  1. Finish enabling ESLint on all our JavaScript code in mozilla-central

We are already covering the vast majority of production code in mozilla-central, however there are still a lot of unit tests that aren’t covered. Increasing linting coverage here will help to ensure these are functioning as we expect.

There’s always a few things it won’t make sense for, e.g. third-party imports, or the occasional piece of preprocessed code, but I think we should strive towards 100% coverage where we sensibly can.

  1. Harmonize our rules

Whilst we have a core set of rules, various directories are overriding and extending the rules. We should aim for having the majority of rules being the same everywhere, with additional rules being only occasional (e.g. experimental).

This will make it far easier for developers working across modules to be able to work in a consistent style, and help spread the useful rules across the tree.

Example rules that fall into this category: mozilla/var-only-at-top-level, block-scoped-var, no-shadow, no-throw-literal, no-unused-expressions, yoda

  1. Improve developer tools

For me, I find most use for ESLint when it is integrated into my editor. However, there’s various other occasions where we’re not doing quite enough to make it easy for developers, e.g. automatically installing hooks, or setting up editor support automatically.

These help developers to catch issues earlier whilst the developer is still focussed on the patch, reducing context switching. We should be getting these working as seamlessly as possible.

  1. Improve automatic fixing

Currently the automatic fixing doesn’t work fully if you run it across the whole tree (you can run it in segments), we should fix it to help make applying new rules globally a lot easier.

We need your help!

  • Find a problem with ESLint that is stopping you using it efficiently? Please file a bug. Alternately, come talk to me about issues that are slowing you down or getting in the way.
  • Reasonably regularly I file mentored bugs for enabling new directories or rules, which are great to get you started. However, if you’re interested in working with me on getting larger chunks going, please let me know (in the comments or ping Standard8 on IRC).
  • Anything I’ve missed or discussions points? Please add a comment.

Thank you

I’d like to say a big thank you to all those that have helped bring ESLint to where it is today. Special thanks go to Dave Townsend for his encouragement and many reviews.

There’s many more people that have been involved from the various teams that work on Firefox, as well as first-time contributors – too many to name, so thank you all!

Running ESLint on commit for mozilla-central (Git & Mercurial)

A while ago, Dave Townsend wrote a commit hook for Mercurial for ESLint. I’ve just extended the code to create a commit hook for Git users.

To install the Git hook, go into the top-level of your mozilla-central Git repository, and enter (assuming you don’t already have a pre-commit hook):

ln -s ../../tools/git/git-lint-commit-hook.sh .git/hooks/pre-commit

That’s all you need to do. If you do have an existing pre-commit hook, then you’ll need to incorporate running git-lint-commit-hook.sh as well.

This will run ESLint on the affected files when committing and print warnings if they fail. The commit will still happen, but you should fix the issues up before pushing them for review.

Coming soon:

WebExtensions: An Example Add-on Repository with Test Harnesses

I’ve created an example repository for how you might set up tools to help development of a WebExtension. Whilst there are others around, I’ve not heard of one that includes examples of tools for testing and auditing your extension.

It is based on various ideas from projects I’ve been working alongside recently.

The repository is intended to either be used as a starting point for constructing a new WebExtension, or you can take the various components and integrate them into your own repository.

It is based around node/npm and the web-ext command line tool to keep it simple as possible. In addition it contains setup for:

All of these are also run automatically on landing or pull request via Travis Ci with Coveralls providing code coverage reports.

Finally, there’s a tool enabled on the repository for helping to keep modules up to date.

If you find it helpful, let me know in the comment section. Please raise any issues that you find, or submit pull requests, I welcome either.