add guards support in JavascriptParser

[vankop]

What kind of change does this PR introduce?
feature
closes #14814

Did you add tests for your changes?
yes

Does this PR introduce a breaking change?
no

What needs to be documented once your changes are merged?
nothing

** notes regarding design **
add in parser.scope parser.scope.guards/parser.scope.inGuardPosition

termins:
guard - chain of ids that is safe to use ( is truthy ) in current parser.scope
in guard position- any possible guard ( chain of ids ) could be added to parser.scope.guards, this means that this guard will be safe to use in current and all children parser scopes. e.g. && logical expression:

import * as b from "b";
// x && y is a guard position since it is truthy only if both operands are truthy, also y could be guarded by x
// b is namespace, always safe to use
// b.a could be a guard
if (b && b.a) {
  if (c) b.a(); // b.a is a guard
}

also 2 binary expressions could be guard position:
x in y / x != y ( when x falsy )
lets assume that y is import specifier then:

import {y} from "y";

// y.x is a guard
"x" in y ? y.x() : null;

// y is a guard
if (null != y) {y();} // non strict equality is important since null !== y could be true with falsy y

also this could work with several guards positions, e.g. complex example:

import {a, b, c} from "a";

//  not in guard position, we support only &&
if ((x in a && b) || c) {
}

if ("x" in a && b || c) {
   a.x(); // is guarded
   b(); // not guarded
   c(); // not guarded
}

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[xarety]

Hey guys, any updates? :)

[alexander-akait]

Code looks good, because will be great to add more tests cases, I’m very afraid of regression, quite a serious change

[vankop]

@alexander-akait fixed

[alexander-akait]

@vankop Looks like we don't have ?. optional chaining, right? And a["b"]?

[vankop]

optional chaining is not supported here.. in general we dont support optional chaining in import specifiers now as I remember, we just opt out optimizations. e.g.

import { a } from 'module';
a.b?.c;
// we optimize only "a.b" so if "b" is a namespace we import all namespace

[vankop]

I guess same for computed part of members expression like a["b"]