jit-prod test is failing CI

[dgp1130]

CI is failing on most branches and blocking RC. https://app.circleci.com/pipelines/github/angular/angular-cli/6157/workflows/14f7b0bd-d3d5-442c-ae94-56d2a6eed305/jobs/146745

I started some preliminary investigation and am able to reproduce by running:

node ./tests/legacy-cli/run_e2e --debug

There is a glob argument to choose the offending test and run just that, but I can't seem to get it to work. This pauses when the test fails and keeps the temporary directory where it ran open.

Going into that directory, ng e2e --prod fails, which is what CI is trying to run. This appears to be testing the example ng new app prod build after setting aot and buildOptimizer to false.

https://github.com/angular/angular-cli/blob/master/tests/legacy-cli/e2e/tests/build/jit-prod.ts

Changing either setting or running without --prod passes the test, so it appears to be coming from this specific set of options.

Running ng serve --prod and visiting the app I can see the full error:

ERROR ReferenceError: Cannot access 's' before initialization
    at Function.get (main.81a14e60f5c105102a14.js:formatted:16209)
    at $t (main.81a14e60f5c105102a14.js:formatted:7246)
    at nf.resolveComponentFactory (main.81a14e60f5c105102a14.js:formatted:14342)
    at Dv.bootstrap (main.81a14e60f5c105102a14.js:formatted:17062)
    at main.81a14e60f5c105102a14.js:formatted:16955
    at Array.forEach (<anonymous>)
    at Tv._moduleDoBootstrap (main.81a14e60f5c105102a14.js:formatted:16955)
    at main.81a14e60f5c105102a14.js:formatted:16939
    at u.invoke (polyfills.f95e9862a91f7a581a3b.js:1)
    at Object.onInvoke (main.81a14e60f5c105102a14.js:formatted:16552)

Jumping to place in the code and formatting nicely I see:

Object.defineProperty(e, Ve, {
                get: ()=>{
                    if (null === n) {
                        const r = je();
                        if (ul(t)) {
                            const n = [`Component '${e.name}' is not resolved:`];
                            throw t.templateUrl && n.push(` - templateUrl: ${t.templateUrl}`),
                            t.styleUrls && t.styleUrls.length && n.push(` - styleUrls: ${JSON.stringify(t.styleUrls)}`),
                            n.push("Did you run and wait for 'resolveComponentResources()'?"),
                            new Error(n.join("\n"))
                        }
                        const s = s;  // <-------------------- ERROR: Cannot access 's' before initialization
                        let i = t.preserveWhitespaces;
                        void 0 === i && (i = null !== s && void 0 !== s.preserveWhitespaces && s.preserveWhitespaces);
                        let o = t.encapsulation;
                        void 0 === o && (o = null !== s && void 0 !== s.defaultEncapsulation ? s.defaultEncapsulation : At.Emulated);

// ...

This appears to be the compiled form of this line which is throwing the error. The source file looks reasonable to me.

I'm pretty sure this optimized format is just wrong. I don't see any scenario where const <identifier> = <same identifier>; would be valid.

const foo = 'test';
if (true) {
  const foo = foo; // ReferenceError: Cannot access 'foo' before initialization
}

I'm not sure how to debug this further, but it seems to be a prod optimization issue when buildOptimizer/aot is disabled.

[filipesilva]

Some extra context from @clydin:

---

Rolling back just @angular/core to 9.1.0-next.5 seems to fix it. Appears related to the optimization of the changes from this PR: angular/angular#35534

I think working around it on the FW side may be the quicker option. Renaming jitOptions to jitCompilerOptions seems to solve the problem (https://github.com/angular/angular/pull/35534/files#diff-c8ff2ff244e44ddf22d9df5edcacc9b1R15)

[filipesilva]

Might be related to terser/terser#612

[filipesilva]

I can confirm that disabling Terser inlining makes the error go away.

[filipesilva]

Made a reproduction of the exact Terser bug in terser/terser#615.

[filipesilva]

Submitted angular/angular#36200 in FW to change the name of the variable, which gets around this bug. This sounds like the best approach while Terser still has the bug.

[dgp1130]

Thanks everyone for the investigation and quick fix!

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}