d3 conventional indentation with eslint

Question

According to the d3 documentation

By convention, selection methods that return the current selection use four spaces of indent, while methods that return a new selection use only two. This helps reveal changes of context by making them stick out of the chain:

Giving code that looks like:

d3.select("body")
  .append("svg")
    .attr("width", 960)
    .attr("height", 500)
  .append("g")
    .attr("transform", "translate(20,20)")
  .append("rect")
    .attr("width", 920)
    .attr("height", 460);

Is there any way to configure eslint to work with this, so that it doesn't complain about unexpected indentaion levels constantly?

The eslint indent rule has a MemberExpression option so you can ignore all indentation for chained method calls, but I want it enforced, just differently for different methods. There's also the ignoredNodes option which can select certain AST nodes to ignore, but I don't know from the documentation if that can select to the fidelity I want. While disabling checking for certain chained methods is not great, it is better than nothing. In that case, I doubt this is a comprehensive list, but all the ones I'm using at four-space indentation are:

.attr()
.style()
.text()
.call()
.on()

So some way to ignore chained method calls with exactly those names, and leave all others at two-space would be an OK stop-gap measure (including methods totally unrelated to d3).

Edit: Removed .data() and .enter() from the list as Gerardo Furtado pointed out they return new selections.

Answer 1

I would focus it differently for 2 reasons:

1. Consistent coding convention across all JavaScript elements which we may develop
2. Automation

As a user of the cross-platform multi-language open-source IDE Visual Studio Code, and since there are highly valuable Visual Studio Code extensions like JS-CSS-HTML Formatter (Id: lonefy.vscode-js-css-html-formatter, current working version 0.2.3), I write code and it indents automatically when needed.

For this particular case, we would use that extension to modify Javascript code on every save, automatically, as it formats code with a decent convention.

I had the workaround of adding built-in commented regions (marked in gray) so that you can help on code visualizing in a similar manner as indent does when folding the code, and this would be the result after saving:

d3.select("body")
    //#region svg
    .append("svg")
    .attr("width", 960)
    .attr("height", 500)
    //#endregion
    //#region g
    .append("g")
    .attr("transform", "translate(20,20)")
    //#endregion
    //#region rect
    .append("rect")
    .attr("width", 920)
    .attr("height", 460)
    //#endregion
;

This is not showing the desired formatting, but here is the trick:

It displays only the green colored //#region inner elements lines when folded, and all inner elements when unfolded

I hope it helps, at least for a consistent and automated convention across your development situations.

JGB