Update doc on no-unused-expressions

[snooopcatt]

Hello.
I think no-unused-expressions doc article could have a note, explaining why is that rule actually matters. Let me tell you a pretty dramatic story with a happy end (short version, for those not believing in fairy tales, is below).

Long version

Once upon a time there was a team of developers who adopted eslint to watch after their young Code. Everything went well, until one day developers decided to utilize fancy ecma getters/setters. And those getters were actually smart and state-changing: if property didn't exist, getter would create one. And they used to trigger getter just by refencing it:

get bar() {
  if (!this._bar) {
    this._bar = 'bar';
  }
  return this._bar;
}

foo() {
  this.bar;
}

ESLint saw this and told them: I won't let you commit this unused-expression noncense! Developers were wondering, what is wrong with this Code? They were new to getters, they did have problem with such form of expression, but they just assumed ecma allows it. So they just calmed down ESLint with an incantation:

foo() {
  // eslint-disable-next-line no-unused-expressions
  this.bar;
}

As they were saying this, ESLint shouted I CURSE YOU! A DAY SHALL COME AND YOU WILL REMEMBER MY WORDS!. Frightened, developers covered their Code with a blanket, woven of the decent test and soon forgot about very scary incident.

Time flew by, and many moons later developers decided they want to try out Angular framework, to see if their Code can play with it. They built a playground, let Angular and Code in, and watched. It was going very well, until one time, they decided to finish this playground by another incantation:

ng build --prod

and as soon as they finished incantation and looked at playground, they saw (OH NO) Code couldn't run! Couldn't even walk!

Developers cared very much about their growing Code, and were eager to help it. So they used ancient magic to see why Code didn't work. They spent hours trying to find cure, they used maps of the production application, but maps didn't show anything useful. Hopes were fading. But then one very old and wise developer, who saw Code being born, noticed that some parts of code were behaving as they were missing key logic. He found few pieces missing, and understood smth: those pieces reeked of magic! There it was, the incantation to silense ESLint, but also it was a curse. It turned out ESLint was right all the way, developers casted a reverse spell, waking up ESLint, they wrapped getter into the dummy function and (OH THE MIRACLE) playground was finished now, built in producton mode and Code was playing joyfully! Developers apologized to ESLint and vowed to be more respectful to it in future. They redid the blanket and used even more decent tests to wove it.
And they lived happily ever after.

Short version:

When we build angular demo in production mode, default setting remove dead code, so snipet below

get bar() {
  if (!this._bar) {
    this._bar = 'bar';
  }
  return this._bar;
}

foo() {
  this.bar; // <- no-unused-expression rule complains
}

will be compiled to smth like:
foo() {}

Although rule has severity level of error, it was not clear why. Code was working perfectly, so we silenced the rule. Then we got very difficult problems to debug in production code.

Conclusion

If you would add a noticeable note to the doc page, saying smth like such code might be deleted during build by some tools (e.g. ng build --prod) it would save hundreds of hours debugging.
Thank you.

[not-an-aardvark]

Hi, thanks for creating an issue. Would you be interested in creating a pull request with the suggested documentation changes?