<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I would like to propose that we require dangling commas for
      multi-line object/arrays in Javascript code for mozilla-central.</p>
    Why:
    <ul>
      <li>Multiple components in toolkit/ and browser/ already <a
          moz-do-not-send="true"
href="https://searchfox.org/mozilla-central/search?q=comma-dangle&case=false&regexp=false&path=">have
          comma-dangle enabled</a>.</li>
      <li>Having asked around in a few locations, I'm seeing support
        from the Firefox developer team and others in favour of enabling
        it.</li>
      <li>It helps make blame cleaner.</li>
      <li>It makes editing easier, and helps for a consistent style.</li>
      <li>Having automation available to cover the requirement reduces
        the need for review nits.</li>
    </ul>
    <p>I realise not everyone necessarily loves the style, but having
      the cleaner blame, and consistent style requirements seems to
      outweigh the downsides.<br>
    </p>
    <p>How:</p>
    <ul>
      <li>We would enable this via an ESLint rule, <a
          href="https://eslint.org/docs/rules/comma-dangle">comma-dangle</a>,
        with the "always-multiline" option set.</li>
      <li>ESLint is able to automatically fix code that doesn't conform
        (e.g. <a moz-do-not-send="true"
          href="https://bugzilla.mozilla.org/show_bug.cgi?id=1476228">bug
          1476228</a> was entirely automatically generated very quickly)<br>
      </li>
    </ul>
    <p>Since there are a large amount of instances (approx 12k) that
      would need to be fixed across the code base, I would propose that
      we roll it out on a per-directory basis. For example, we could do
      all of browser/ at the start of the 64 cycle just after the merges
      (alternately the end of the 63 cycle during soft freeze), then do
      toolkit/ at the next merge time, and then pick up the rest at the
      end. This will limit the scope of possible bitrotting to smaller
      chunks, as well as making the patch sizes more manageable.<br>
    </p>
    <p>This will only cover directories that ESLint currently covers -
      though as we roll out ESLint to new directories, they'll be
      covered automatically.<br>
    </p>
    <p>Feedback & thoughts welcome.</p>
    <p>Standard8<br>
    </p>
  </body>
</html>