1. The users of this style guide will probably expect that all of the rules that it prescribes will be enforced by eslint. However, this is not the case - there is a secret, non-documented segmentation where some rules are enforced and others are not, because they would be "too noisy on a legacy codebase". An example of a problematic rule like this is covered in issue #2020. I propose that all of

I opened this issue to discuss how can we improve the docs.

It's very valuable the input from users, as I have a deep knowledge of the library already, so my view doesn't help a lot.

We can start compiling a list of things we need to add, like another tutorial, some how-to sections, a better readme or doc home page and so on.

It'd be nice if we could include the functions x => f(x) under the definition of trivial. For example, if we want to call Array.map(x => f(x)) sometimes there are optional extra parameters of f that don't necessarily coincide with the parameters Array.map passes, and you need to delegate like this.

Another good example is for delegations that use methods, e.g. x => x.f().

Also cons

const rectangle = {
  width: 20, 
  height:10,
  area: 200
}
let {width, heigh, area, perimeter = 60} = rectangle;
console.log(width, height, area, perimeter)  //20 10 200 60
//Lets modify the object:width to 30 and perimeter to 80
const rectangle = {
  width: 30, 
  height:10,
  area: 200,
  perimeter:80
}
let {width, heigh, area, perimeter = 60} = rectangle;
console.log(width