Tag: firefox

About 4 years and 2 months ago, Dave Townsend and I landed a couple of patches on the Mozilla codebase that kick-started rolling out ESLint across our source code. Today, I’ve just landed the last bug in making it so that ESLint runs across our whole tree (where possible).

ESLint is a static analyser for JavaScript that helps find issues before you even run the code. It also helps to promote best practices and styling, reducing the need for comments in reviews.

Several Mozilla projects had started using ESLint in early 2015 – Firefox’s Developer Tools, Firefox for Android and Firefox Hello. It was clear to the Firefox desktop team that ESLint was useful and so we put together an initial set of rules covering the main desktop files.

Soon after, we were enabling ESLint over more of desktop’s files, and adding to the rules that we had enabled. Once we had the main directories covered, we slowly started enabling more directories and started running ESLint checks in CI allowing us to detect and back out any failures that were introduced. Finally, we made it to where we are today – covering the whole of the Firefox source tree, mozilla-central.

Along the way we’ve filed over 600 bugs for handling ESLint roll-out and related issues, many of these were promoted as mentored bugs and fixed by new and existing contributors – a big thank you to you all for your help.

We’ve also found and fixed many bugs as we’ve gone along. From small bugs in rarely used code, to finding issues in test suites where entire sections weren’t being run. With ESLint now enabled, it helps protect us against mistakes that can easily be detected but may be hard for humans to spot, and reduces the work required by both developer and reviewer during the code-review-fix cycle.

Although ESLint is now running on all the files we can, there’s still more to do. In a few places, we skipped enabling rules because it was easier to get ESLint just running and we also wanted to do some formatting on them. Our next steps will be to get more of those enabled, so expect some more mentored bugs coming soon.

Thank you again to all those involved with helping to roll out ESLint across the Firefox code-base, this has helped tremendously to make Firefox’s and Gecko’s source code to be more consistently formatted and contain less dead code and bugs. ESLint has also been extremely helpful in helping switch away from older coding patterns and reduce the use of risky behaviour during tests.

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.

2. 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

3. 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.

4. 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!