I think PR #688 is awesome, so here is it with the merge conflicts fixed.

Coverage remained the same at 87.765% when pulling 8161e90 on Br3nda:bw/bar_graphs into aea935b on Growstuff:dev.

Color literals like #ffa500 should only be used in variable declarations; they should be referred to via variable everywhere else.

I don't think that's used anywhere else (its... orange); though we do have

$beige: #f3f1ee
$brown: #413f3b

$green:  #5f8e43
$blue:   #2f4365
$red:    #8e4d43
$orange: #b2685c
$yellow: #b2935c

Weirdly; #b2685c is completely not orange. I didn't quite see where it was used in the UI looking at the code only

I think with the d3 'similar code', its just going to be something we ignore. Specifically:

Similar code found in 1 other location (mass = 73)
NEW
    return d3.append('g')
      .attr("class", "bar-label")
      .selectAll("text")
      .data(bars.map(function(bar){ return bar.name;}))
      .enter()

To ignore this duplication issue modify your .codeclimate.yml file and add 16dbcb58d6caa7ccfe241417831ecfa6 to exclude_fingerprints. An example is shown below.

.codeclimate.yml
engines:
  # ... CONFIG CONTENT ...
  duplication:
    enabled: true
    # ... CONFIG CONTENT ...
    exclude_fingerprints:
    - 16dbcb58d6caa7ccfe241417831ecfa6
# ... CONFIG CONTENT ...

for (i; i < data.bars.length; i++){
      barValues.push(data.bars[i].value)
    }

Kind of keen to see if we can barValues.push(data.bars.map(function(bar) { return bar.value; });

Coverage remained the same at 88.39% when pulling fe5a931 on Br3nda:bw/bar_graphs into 3e43a19 on Growstuff:dev.

Coverage remained the same at 88.39% when pulling fe5a931 on Br3nda:bw/bar_graphs into 3e43a19 on Growstuff:dev.

Css isn't my thing. Anyone who can quickly work out how to appease code climate?

Coverage remained the same at 88.39% when pulling 27520e9 on Br3nda:bw/bar_graphs into 148dfa7 on Growstuff:dev.

Coverage remained the same at 88.39% when pulling 27520e9 on Br3nda:bw/bar_graphs into 148dfa7 on Growstuff:dev.

The one-line duplication between bar_group.js and width_scale.js looks trivial, but actually it's one identical line embedded in two functions which are logically identical but just different enough to fool CodeClimate. So it would be good to factor that out. The function in question boils down to bars.map(function(bar) { return bar.value; }), which I see you're using in the other "similar code found" issue - can we rely on the map method existing?

The "similar code found between bar_group.js and bar_label_group.js" issue looks like a false positive to me - sure, we could factor out some common code, but the similarity is superficial so we wouldn't gain anything thereby. To ignore it, add 16dbcb58d6caa7ccfe241417831ecfa6 to engines.duplication.exclude_fingerprints in .codeclimate.yml, as follows:

engines:
  # ... CONFIG CONTENT ...
  duplication:
    enabled: true
    # ... CONFIG CONTENT ...
    exclude_fingerprints:
    - 16dbcb58d6caa7ccfe241417831ecfa6
# ... CONFIG CONTENT ...

Oh, @CloCkWeRX already said everything I did a fortnight ago. D'oh. Oh well, at least I'm somewhat up to speed with the issues now.

can we rely on the map method existing

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map - mostly.

Coverage remained the same at 89.006% when pulling 0c8345d on Br3nda:bw/bar_graphs into 58ddeef on Growstuff:dev.

Coverage remained the same at 89.006% when pulling 0c8345d on Br3nda:bw/bar_graphs into 58ddeef on Growstuff:dev.

We can use jQuery.map: we're already using jQuery.