Consider our divergences from style standards

[zachmullen]

@matthewma7 's document made me take a look at our divergence from airbnb style. We only have three rules, we should be deliberate about each such divergence.

1. no-underscore-dangle: 0. I use _-prefixed names as a convention to indicate private symbols in an API, but we can achieve that more formally by using Symbol. What do you guys think? I'm happy to make this change if we are OK with it.
2. import/prefer-default-export: 0. I disabled this because I had a module that only exported one thing at the time that I wrote it, but it was not a sensible default export (I think it was the mixins module, and there was only one mixin). This strikes me as something we could instead do with inline disables for those cases when we want to break it.
3. no-param-reassign: ["error", { "props": false }]. We just had a discussion here about this one, and seem to have come to a consensus to globally set it. Of the three of these, this is the one I would argue keeping around.

Keeping this to a minimal set will make it simpler to share between here and resonantgeo.

[matthewma7]

no-underscore-dangle: 0

I think underscores are perfectly fine. Symbol add complexity and will make it really private so a situation like "just let me override it I know what I am doing!" could happen. Unlike, when people using _ stuff, they know they did something unorthodox and will take responsibility for maintaining it, but at the end of the day, the monkey patched code works.

I agree with the 3, and 2 is comparatively rare so, agree, we can do individually.

[zachmullen]

There's a major complication with the underscore rule in our case, which is that we receive objects from the server, and they all have keys in them with dangling underscores. That would make it very difficult to manage the no-underscore-dangle rule for us, so I'm happy to leave it disabled.

[brianhelba]

FYI, no-underscore-dangle allows whitelisting of specific names (like _id), if you still want to use the rule generally.