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!

Bookmarks changes in Firefox Nightly – Testing Wanted

There’s been a project that’s been going on for several years to move Firefox’s bookmarks processing off the main thread and to happen in the background – to help reduce possible jerkiness when dealing with bookmarks.

One part of this (Places Transactions) has been enabled in Nightly for about 4-5 weeks. We think we’ve fixed all the regressions for this, and we’d now like more people testing.

So, when you’re checking out the improved performance of Firefox Nightly, please also keep an eye on Bookmarks – if you’re moving/copying/editing them, and you undo/redo actions, check that everything behaves as it should.

If it doesn’t, please file a bug with how to reproduce and we’ll take a look. If you can also test with the preference browser.places.useAsyncTransactions set to false (after a restart) to know if it happens with the old style transactions – that will help us finding the issue.

We know there’s still some performance issues with the new async transactions which we’re currently working on and hope to be landing fixes for those soon.

Windows trunk nightly updates broken

The update code that drives the automatic updates was changed at the end of last week, and unfortunately this broke the update mechanism on Windows.

If you downloaded a trunk nightly build on Saturday or Sunday, then you may be affected. You’ll know this is the case if you get a dialog stating “The update could not be installed (patch apply failed)”.

The cause has now been fixed and was included in Monday’s nightly builds.

If this affects you, you will need to download and install a new nightly build from one of these locations: